Delay-Tolerant Networking B. Sipos Internet-Draft JHU/APL Intended status: Standards Track 19 July 2026 Expires: 20 January 2027 Bundle Protocol (BP) Manifest Block draft-sipos-dtn-manifest-block-01 Abstract This document defines an extension block type for Bundle Protocol version 7 to capture discretionary summary data about the state of a Bundle at the time the extension block is added. This Manifest structure is a general purpose container for information about other blocks, and can be used as a piece-part of a larger security operation. 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 20 January 2027. Copyright Notice Copyright (c) 2026 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. Sipos Expires 20 January 2027 [Page 1] Internet-Draft BP Manifest July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Manifest Block Content . . . . . . . . . . . . . . . . . . . 4 2.1. Well-known Metadata Items . . . . . . . . . . . . . . . . 7 2.1.1. Manifest Source . . . . . . . . . . . . . . . . . . . 7 2.1.2. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Common Block Items . . . . . . . . . . . . . . . . . . . 8 2.2.1. Block Flags . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. BTSD Length . . . . . . . . . . . . . . . . . . . . . 8 2.2.3. BTSD Hash . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Security Block Items . . . . . . . . . . . . . . . . . . 9 2.3.1. Security Targets . . . . . . . . . . . . . . . . . . 9 2.3.2. Security Context ID . . . . . . . . . . . . . . . . . 10 2.3.3. Security Key ID . . . . . . . . . . . . . . . . . . . 10 3. Manifest Processing . . . . . . . . . . . . . . . . . . . . . 11 3.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Verification . . . . . . . . . . . . . . . . . . . . . . 11 4. Initial Manifest Reasons . . . . . . . . . . . . . . . . . . 12 4.1. Preserve Extensions . . . . . . . . . . . . . . . . . . . 12 4.2. Security AAD Hashing . . . . . . . . . . . . . . . . . . 13 4.3. Security Sourcing . . . . . . . . . . . . . . . . . . . . 15 4.4. Security Acceptance . . . . . . . . . . . . . . . . . . . 16 5. Operational Considerations . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 17 6.2. Threat: Weak Hash Algorithms . . . . . . . . . . . . . . 17 6.3. Threat: Untrusted Manifest . . . . . . . . . . . . . . . 17 6.4. Threat: Manipulated Manifest . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.1. BPv7 Block Type . . . . . . . . . . . . . . . . . . . . . 18 7.2. Manifest Registries . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Sipos Expires 20 January 2027 [Page 2] Internet-Draft BP Manifest July 2026 1. Introduction The structure of the protocol data unit for Bundle Protocol (BP) version 7 [RFC9171] divides each independent Bundle into a sequence of blocks. The first "primary" block is mandatory and immutable during the Bundle lifetime, the last "payload" block is mandatory and contains the application data unit (ADU) being transported, and all other blocks in between them are "extension" blocks of various types and ordering as needed by functions of the BP network. Each non- primary "canonical" block (Section 4.3.2 of [RFC9171]) of a Bundle contains a block type code point, a unique-to-the-bundle block number, and block-type-specific data (BTSD) of a byte string with content encoded and interpreted according to the associated block type. While the primary and payload blocks are mandatory, each extension block instance (not just type) will have a lifecycle controlled by policy and configuration on each node along its path from source to destination (including those two end nodes). Any extension block present at some point along that path will have been created along with or after the Bundle and will be discarded along with or before the Bundle. Some of the extension blocks provide security operations, for integrity or confidentiality, in accordance with Bundle Protocol Security (BPSec) [RFC9172]. The purpose of the Manifest block type specified in this document is to allow a node to capture some or all of the state of a Bundle as that Bundle transits the node (either as the source or an intermediate forwarding node). Each manifest includes metadata about when and why it was created as a way for later users of the block to filter Manifests based on policy. One initial use case for a Manifest, defined in Section 4.2, is to optimize how a security operation targeting one block can be bound to the state of other blocks at the time the operation is added to a Bundle. 1.1. Scope This document describes the encoding and interpretation of the BTSD content for the Manifest block type, and its initial reason codes and use cases. This document does not address: * Other potential Manifest reason codes, which can be defined in other specifications and either registered with IANA or use codes from the private use block. * Policies or mechanisms for when and how other extension blocks are added to, modified in, or discarded from a Bundle. Sipos Expires 20 January 2027 [Page 3] Internet-Draft BP Manifest July 2026 * Policies about when and how BPSec security operations targeting or covering a Manifest block are added to, modified in, or discarded from a Bundle. 1.2. Use of CDDL This document defines CBOR structure using the Concise Data Definition Language (CDDL) [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression: '//sourcecode[@type="cddl"]' The following initial fragment defines the top-level symbols of this document's CDDL. start = ext-data-manifest The definitions for the rules dtn-time, and extension-block, block- control-flags, the socket $extension-block, and the generic rule extension-block-use are taken from BP [RFC9171]. 1.3. Terminology 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. 2. Manifest Block Content The BTSD content for the Manifest block type consists of a CBOR sequence [RFC8742] of a reason code and a metadata map followed by an array of block identities and block-derived data maps. Each other block referenced by a Manifest is referred to here as "covered" by that Manifest, with details of that covering indicated by the labels of each block data maps. This structure is illustrated in Figure 1. Sipos Expires 20 January 2027 [Page 4] Internet-Draft BP Manifest July 2026 +----------------+ | Reason Code | \ +----------------+ Header | Metadata Map | parts | Item(s) | / +----------------+ +----------------+ | Block Identity | \ +----------------+ Repeated in array | Block Data Map | for each covered block | Item(s) | / +----------------+ Figure 1: Notional Manifest Structure The mandatory reason code is used to convey the reason why the Manifest was created, the audience for its verification, and how it is intended to be used. The reason code SHALL be of type int16 interpreted according to the "Manifest Reason Codes" IANA registry defined in Section 7.2. Items in the metadata map SHALL be interpreted according to the "Manifest Metadata Items" IANA registry defined in Section 7.2. Its initial contents are defined in Section 2.1 in text and CDDL. The coverage of blocks by a single Manifest is discretionary to the node creating the Manifest (see Section 3.1). A single Manifest does not not need to cover all blocks present at the time of its creation, and which blocks are covered will depend on the reason why the Manifest was created. The creator of a Manifest block MAY cover any other block present in the Bundle in accordance with requirements of the reason code. A verifier of a Manifest block SHALL NOT assume or rely on a Manifest to cover any or all other blocks in the Bundle. Each covered block is represented in the Manifest data as a tuple of block identity fields and a block data map, and all of these SHALL be enveloped in a definite-length CBOR array. This means that the length of this array will always be a multiple of three. Any received Manifest block which contains a covered block array with a length that is not a multiple of three items SHALL be considered invalid and handled according to the normal block processing rules of BP. The mandatory block identity fields are the block type code, used to condition contents of the following block data map, and the block number, used to uniquely identify the covered block at the time the Manifest is created. In accordance with Section 4.3.2 of [RFC9171], both the block type and block number SHALL be of type uint with Sipos Expires 20 January 2027 [Page 5] Internet-Draft BP Manifest July 2026 values copied directly from the covered block. All items in the associated block data map are about the block referenced by this block number. These fields are in the same order as the first two items of the canonical block array encoding [RFC9171]. Items in each block data map SHALL be interpreted according to the "Manifest Data Items" IANA registry defined in Section 7.2. Its initial contents are defined in Section 2.2 in text and CDDL. This structure is represented in the CDDL of Figure 2, which uses the $extension-block socket from Appendix B of [RFC9171]. ; Manifest is encoded in BTSD content as a sequence ; EDITOR NOTE: block type 255 is a placeholder for IANA assignment $extension-block /= extension-block-use<255, (bstr .cborseq ext-data-manifest / bstr)> ext-data-manifest = [ reason: int16, metadata-map, [* blockdata-grp] ] ; Tuple for each covered block blockdata-grp = ( ; From the IANA Bundle Block Types registry block-type: uint, ; Cross-reference to covered block block-num: uint, blockdata-map ) ; Controlled by metadata-item socket metadata-map = {* $$metadata-item } .within manifest-structure ; Controlled by blockdata-item socket blockdata-map = {* $$blockdata-item } .within manifest-structure ; General structure of all maps in the manifest manifest-structure = { * int16 => any } int16 = -32768 .. 32767 Figure 2: Manifest BTSD Content CDDL Sipos Expires 20 January 2027 [Page 6] Internet-Draft BP Manifest July 2026 A block covered by a Manifest MAY be the target of a BPSec confidentiality operation before or after creation of the Manifest. It is a deployment and usage consideration to ensure that policy controlling Manifest lifecycles is consistent with policy controlling confidentiality lifecycles. A block covered by a Manifest MAY be discarded at any time after creation of the Manifest. One potential future reason for a Manifest would be to record when specific blocks _are_ discarded by a node. 2.1. Well-known Metadata Items The metadata items, and their keys, defined in this section apply only to the first map within the Manifest BTSD content. These items relate to the creation of the Manifest itself and not to any individual blocks covered by the Manifest. In addition to the well-known items, there are code blocks in Table 3 reserved for private and experimental use. 2.1.1. Manifest Source This item is used to represent the source node of the enclosing Manifest block. This item SHALL use map key 2 and value of a bstr- wrapped EID value. This enveloping is in accordance with recommendations in Section 4 of [I-D.ietf-dtn-eid-pattern]. $$metadata-item //= ( 2: embed-eid-structure ) ; Same as [draft-ietf-dtn-eid-pattern] embed-eid-structure = bstr .cbor eid-structure Figure 3: Manifest Source CDDL 2.1.2. Timestamp The item is used to represent the absolute time of the local timekeeper on the source of the Manifest block when it was created. This item SHALL use map key 3 and value of a dtn-time in accordance with Section 4.2.6 of [RFC9171]. $$metadata-item //= ( 3: dtn-time ) Figure 4: Timestamp CDDL Sipos Expires 20 January 2027 [Page 7] Internet-Draft BP Manifest July 2026 2.2. Common Block Items The block data items, and their keys, defined in this section apply to all block types equivalently and can be present for any associated block type. These items relate to the BPv7 canonical block structure as defined in Section 4.3.2 of [RFC9171] without concern for the specific block type or content of the BTSD. 2.2.1. Block Flags This item is used to convey the "Block processing control flags" value at the time the Manifest is created. This item SHALL use map key 2 and value of a uint representing the flags. $$blockdata-item //= ( 2: block-control-flags ) Figure 5: Block Flags CDDL Verification of this item SHALL consist of matching the item value against the Block processing control flags of the referenced block. 2.2.2. BTSD Length This item is used to convey the length of the BTSD content (_i.e._, the argument of the CBOR head of the BTSD item) at the time the Manifest is created. This item SHALL use map key 5 and value of a uint representing a length in bytes. $$blockdata-item //= ( 5: btsd-len ) btsd-len = uint Figure 6: BTSD Length CDDL Verification of this item SHALL consist of matching the item value against the length of the BTSD of the referenced block. 2.2.3. BTSD Hash This item is used to convey a concise summary of BTSD content (_i.e._, the byte string within the BTSD item) without revealing the content itself. This item SHALL use map key 6 and value of an array containing a sequence of pairs of items. Each pair SHALL consist of a "COSE Algorithms" value [IANA-COSE] representing the hash algorithm used, and the hash as a bstr. The input to the hash SHALL be the Sipos Expires 20 January 2027 [Page 8] Internet-Draft BP Manifest July 2026 content of the BTSD of the referenced block, excluding any CBOR head associated with the BTSD item itself. $$blockdata-item //= ( ; One or more pair of hash outputs 6: [+ btsd-hash] ) btsd-hash = ( ; From the IANA COSE Algorithms registry alg: tstr / int, value: bstr ) Figure 7: BTSD Hash CDDL Verification of this item SHALL consist of matching at least one of the BTSD Hash values included in the Manifest against a locally computed hash of the content of the BTSD of the referenced block. It is expected that truncated hash algorithms (_e.g._, SHA-256/64) can be used to trade hash output size for security strength. The choice of which hash algorithm(s) to use for any covered block is an implementation decision (and discussed in Section 6.2). 2.3. Security Block Items The block items, and their keys, defined in this section SHALL apply only to block types for Block Integrity (11) and Block Confidentiality (12). These items relate to the abstract security block (ASB) structure as defined in Section 3.6 of [RFC9172] within its BTSD content. 2.3.1. Security Targets This item is used to convey the target block numbers present in the security block at the time the Manifest is created. This item SHALL use map key -1 and value of an array of uint representing block numbers. The order of the target block numbers in this item SHOULD be the same as the original security block. $$blockdata-item //= ( -1: bpsec-targets ) bpsec-targets = [+ uint ] Figure 8: Security Targets CDDL Sipos Expires 20 January 2027 [Page 9] Internet-Draft BP Manifest July 2026 Verification of this item SHALL consist of matching the targets array in this item against the targets field of the ASB decoded from the referenced security block. It is not relevant to this verification as to whether or not the referenced target blocks themselves are present. 2.3.2. Security Context ID This item is used to convey the Context ID field at the time the Manifest is created. This item SHALL use map key -2 and value type int16 representing one of the "BPSec Security Context Identifiers" [IANA-BUNDLE] from the security block. $$blockdata-item //= ( -2: int16 ) Figure 9: Security Context CDDL Verification of this item SHALL consist of matching the value of this item against the context ID of the ASB decoded from the referenced security block. It is not relevant to this verification as to whether or not the security context is known to the verifying node. 2.3.3. Security Key ID This item is used to convey the Key ID used to process a security operation within a security block. This item SHALL use map key -3 and value type bstr representing the Key ID used to process a security operation. This Key ID is not present in the encoded ASB for Default Security Contexts [RFC9173] and can be ambiguous when multiple recipients or signers are present for the COSE Context [I-D.ietf-dtn-bpsec-cose], so it is an implementation matter to determine the appropriate Key ID value to use for a particular operation. This also means that the Key ID cannot be defined for cases where the Manifest creator does not have a configured role to process the security operation. $$blockdata-item //= ( -3: bstr ) Figure 10: Security Key ID CDDL Sipos Expires 20 January 2027 [Page 10] Internet-Draft BP Manifest July 2026 Because this item represents internal state within the security processor, it cannot be verified against the ASB decoded from the referenced security block. This field is only useful for correlating with expected values outside of the manifest verification procedure. 3. Manifest Processing There are two processing activities associated with the Manifest block type: creating the manifest and verifying it. Those are defined in the following subsections. A Manifest is intended to be a snapshot of part of the Bundle state at its time of creation. There is no defined concept of a Manifest being manipulated by an intermediate node; any manipulation would be the result of bad configuration or an on-path attack (Section 6.4). 3.1. Creation The decision of when and why a Manifest is created and added to a Bundle is a local policy decision on a node. The Reason item SHALL be present in all metadata maps. This metadata item is needed by other nodes to filter Manifest blocks and to interpret their semantics. The definition of a reason code can refine and require specific metadata or block data items to be present (see Section 4). The selection of which blocks to cover by a Manifest is also a local policy decision and likely depends on the Reason code. Each covered block will correspond with a separate block data map. The Block Identity item SHALL be present in each block data map. All of the other items in the block data map depend on its block number to create and verify, and some (specifically negative keys) depend on its block type. 3.2. Verification The general Manifest verification procedure checks items in each block data map against the actual block data. Because blocks can be discarded after a Manifest has been created, one possible outcome for an individual block verification is that the block is missing; a missing covered block is a valid outcome and does not affect the verification of other blocks referenced by the same Manifest. It is a policy decision for how to act upon the outcome of verification, including cases of missing covered blocks. Sipos Expires 20 January 2027 [Page 11] Internet-Draft BP Manifest July 2026 The verification of a Manifest SHALL include checking whether the Manifest covers a minimum set of blocks, and if each block data map contains a minimum set of items. It is a matter of local policy on a verifier (within constraints for the associated Reason) to determine the minimum acceptable coverage for any particular Manifest. The verification of a Manifest SHALL include verification of each item contained in each block data map based on the individual item definitions. It is an implementation matter to determine whether verification of a single block needs to stop on the first failure or continue to verify all items. The definition of a reason code can refine and require specific metadata or block data items to succeed in verification (see Section 4). 4. Initial Manifest Reasons This section defines the semantics and constraints of manifest reason codes for the initial registry assignments in Table 2. 4.1. Preserve Extensions When bundles are being forwarded through one or more transit networks on their path from source to destination, it is useful to be able to mark at ingress which extension blocks need to be preserved during the transit across those networks. This marking could be created by the edge nodes themselves or by a routing node on either side of the ingress hop. The Manifest reason "Preserve Extensions" (code 2) SHALL be used to indicate that the Manifest block is intended to mark one or more blocks as needing to be kept in the Bundle until the Manifest itself is discarded. When this reason is present, the block itself SHALL be marked with block processing control flags having bit 2 set, indicating "Delete bundle if block can't be processed." When this reason is present, each block data map MAY contain a BTSD Length (key 5) and/or BTSD Hash (key 6). When verifying for this reason, if any block is missing or has a mismatch with the Manifest the entire verification SHALL be considered to have failed. Sipos Expires 20 January 2027 [Page 12] Internet-Draft BP Manifest July 2026 4.2. Security AAD Hashing The definition of external additional authenticated data (AAD) in the BPSec COSE context [I-D.ietf-dtn-bpsec-cose] allows an arbitrary number of other blocks (both canonical block metadata and BTSD) to be bound to a security operation on a single target block. Using external AAD coverage allows a security verifier or acceptor to assert that (a chosen subset of) the state of those other blocks at the time of verification matches their state at the time the operation was added to the Bundle. The use of direct BTSD-in- external-AAD is depicted in Figure 11. A side effect of AAD directly covering the BTSD of other blocks is the need to serialize that BTSD as input to the COSE message processing, at the security source and for all verifiers and acceptors. For cases where the AAD covers large BTSD, including that of the payload block, this can impose a large data handling burden on the security processing entity (specifically its cryptographic element). Target BTSD +----------------+ | | +--------+---+ +--------v---+ +------------+ | Security | | Target | | Other | | Block | | Block | | Blocks... | +---^----+---+ +---^--------+ +---^----^---+ | | | | | +----+-----------+--------------+----+ AAD from any block header or BTSD Figure 11: Security AAD Using Other Blocks Directly A common way to mitigate this need for cryptographic processing of large data is distill the data using a hash algorithm and then use the hash value as input to the cryptographic function. This technique of "preimage hashing" is available for the target of a security operation using a COSE Hash Envelope [RFC9995] but is not available for its external AAD, so a large block with its BTSD as part of security operation AAD will constrain the processing of that operation (both as security source and verifier/acceptor). A straightforward use of a Manifest block, defined later in this section, is to capture the hash values of other blocks for external AAD coverage and thus reduce the size of that external AAD needed as cryptographic input. Sipos Expires 20 January 2027 [Page 13] Internet-Draft BP Manifest July 2026 Target BTSD +---------------------------------+ | | +--------+---+ +------------+ +--------v---+ +------------+ | Security | | Manifest | | Target | | Other | | Block | | Block | | Block | | Blocks... | +---^----+---+ +---^----^-+-+ +---^--------+ +---^----^---+ | | | | \ | | | +----+-----------+----+ --------+--------------+----+ AAD (header + BTSD) Cover with header + BTSD Hash Figure 12: Security AAD Using a Manifest Because some block types will necessarily have a small expected BTSD length, this use case involves a trade between using a hashing manifest, to guarantee external AAD size, and just using the other block BTSD in the AAD scope directly. For example, when using an overall security strength needing a SHA-384 hash a BTSD Hash item will contain a bstr value of 48 bytes. If the other block being included is a Hop Count type (Section 4.4.3 of [RFC9171]) it will never have a BTSD larger than 19 bytes (or more realistically, for hop limits below 64k, no larger than 7 bytes). It is an implementation matter by the manifest and security source to determine how and when to apply BTSD hashing for external AAD. This still can be somewhat mitigated by using existing hash algorithms which have truncated outputs. It is an implementation matter to choose hashing algorithms for the manifest. The Manifest reason "Security AAD Hashing" (code 1) SHALL be used to indicate that the Manifest block is intended to distill the BTSD of one or more blocks in the Bundle to be included in some security scope. For this use case the Manifest Source will be identical to the Security Source of the security block using this Manifest in its AAD scope. When this reason is present, each block data map SHALL contain the following items: * Block Flags (key 2) * BTSD Hash (key 6) When this reason is present, each block data map MAY contain a BTSD Length (key 5). When verifying for this reason, if any block is missing or has a mismatch with the Manifest the entire verification SHALL be considered to have failed. Sipos Expires 20 January 2027 [Page 14] Internet-Draft BP Manifest July 2026 When a Manifest with this reason is included in the target or AAD scope of a security operation, the full verification of that operation SHALL include verifying the Manifest. This logic does not need to be implemented as part of BPSec processing, but can be done as part of larger security policy alongside BPSec proper. Although successful verification now requires both BPSec verification and Manifest verification, the order in which these two occur can be done in either order (or even concurrently). Choosing a desirable order allows an implementation to optimize further for expected success and failure modes. 4.3. Security Sourcing When a BPSec security operation is created by a node, as its security source, the security target and its associated security results are embodied within the ASB structure of its parent security block. Because the ASB retains no history of security actions, later updates in the lifecycle of the security operation can cause the parent security block to be modified or even discarded (_e.g._, if the operation is accepted before the destination node). The reason defined in this section allows security sourcing to be recorded for downstream auditing [I-D.tian-dtn-sbam]. The Manifest reason "Security Sourcing" (code 3) SHALL be used to indicate that the Manifest block is intended to record the actions of a security source as defined by BPSec [RFC9172]. When this reason is present, each covered block identity SHALL have block type of either 11 or 12. When this reason is present, each block data map SHALL contain the following items: * Security Targets (key -1) * Security Context ID (key -2) * Security Key ID (key -3) Multiple block data maps MAY be present as needed to indicate all sourcing actions performed by the node across any security blocks in the Bundle. Because this reason is meant to be used separately from the covered security blocks themselves, with a likely longer block lifecycle, the containing Manifest is not meant to be verified (in the sense of Section 3.2) by any node. This reason can be coupled with Security Acceptance manifest(s) to audit the lifecycles of those covered security blocks. Sipos Expires 20 January 2027 [Page 15] Internet-Draft BP Manifest July 2026 4.4. Security Acceptance When a BPSec security operation is accepted by a node, the security target and its associated security results are removed from the ASB structure of its parent security block. Because the ASB retains no history of security actions, a removal due to acceptance is not visible downstream from the acceptor node any differently than malicious removal by an on-path attacker. The reason defined in this section allows security acceptance to be recorded for downstream auditing [I-D.tian-dtn-sbam]. The Manifest reason "Security Acceptance" (code 4) SHALL be used to indicate that the Manifest block is intended to record the actions of a security acceptor as defined by BPSec [RFC9172]. When this reason is present, each covered block identity SHALL have block type of either 11 or 12. When this reason is present, each block data map SHALL contain the following items: * Security Targets (key -1) * Security Context ID (key -2) * Security Key ID (key -3) Multiple block data maps MAY be present as needed to indicate all acceptance actions performed by the node across any security blocks in the Bundle. Because this reason is meant to be used when the referenced security operations (and their security targets) are removed from their parent security blocks, the containing Manifest is not meant to be verified (in the sense of Section 3.2) by any node. It is a recording of what _was_ present before the security acceptance and meant to be coupled with either Security Sourcing manifest(s) or out-of-band information about expected security operations. 5. Operational Considerations This section explains various operational topics based on guidance of the IETF Operations and Management Area Working Group [RFC5706]. 6. Security Considerations This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552]. Sipos Expires 20 January 2027 [Page 16] Internet-Draft BP Manifest July 2026 6.1. Threat: Passive Leak of Bundle Data The use of a Manifest block does not cause any additional visibility of data at the time the Manifest is added to a Bundle. All of its metadata and block data is derived from other block items already visible to any handler of the Bundle. It is possible that a block covered by a Manifest is later made the target of a confidentiality operation and its BTSD becomes ciphertext. Even in this case, the block data items defined by this specification in Section 2 do not directly leak the BTSD, only information _derived from_ the BTSD is present in the Manifest. The strength of the BTSD Hash item is a separate consideration discussed in Section 6.2. Future block data item definitions are RECOMMENDED to consider if and how they reveal information from the BTSD of covered blocks. 6.2. Threat: Weak Hash Algorithms When used as defined in Section 4.2 the hashing function(s) become part of the overall security verification. A weak strength hash algorithm in a Manifest will lower the cryptographic binding to the associated BTSD down to the strength of that hashing. When used as BPSec AAD, the choice of BTSD hash algorithm(s) in a Manifest SHALL be at least as strong as the overall security strength of the associated integrity or confidentiality algorithm(s). 6.3. Threat: Untrusted Manifest The mere presence of a Manifest block in a Bundle does not grant any implied trust for the metadata or block data contained in the Manifest. A BPA can compare the block data within a Manifest with the actual blocks of a Bundle before any related security processing to catch mismatches early, but the results of any such comparison need to be treated as conditional on trust of the Manifest block itself. Beyond the specific use in Section 4.2, each Manifest block SHOULD be the target or AAD of an associated BPSec integrity operation. 6.4. Threat: Manipulated Manifest Any Manifest block which is kept in plaintext (_i.e._, is not the target of a BPSec confidentially operation) is vulnerable to on-path manipulation of its block content, either in-transit or at-rest. Sipos Expires 20 January 2027 [Page 17] Internet-Draft BP Manifest July 2026 The verification requirements in Section 3.2 ensure that entities processing a Manifest block verify not just the contents of the Manifest itself but also verify that the contained block data matches the actual Bundle contents. 7. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of code points in existing registries and creation of new registries in accordance with BCP 26 [RFC8126]. 7.1. BPv7 Block Type IANA has registered, under the "Bundle Protocol" registry group [IANA-BUNDLE], an entry in the registry "Bundle Block Types" with the following information. +=========================+=========+=============+================+ | Bundle Protocol Version | Value | Description | Reference | +=========================+=========+=============+================+ | 7 | | Manifest | [This | | | // TBA1 | | specification] | +-------------------------+---------+-------------+----------------+ Table 1: Bundle Block Types IANA NOTE: The // TBA1 requested value is the lowest unassigned value (13). 7.2. Manifest Registries EDITOR NOTE: registries to-be-created upon publication of this specification. For all of the registries defined in this section, expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). IANA has created, under the "Bundle Protocol" registry group [IANA-BUNDLE], a registry titled "Manifest Reason Codes" and initialize it with the contents of Table 2. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA. Sipos Expires 20 January 2027 [Page 18] Internet-Draft BP Manifest July 2026 +==================+===============================+================+ | Value | Name | References | +==================+===============================+================+ | -32768 to -32641 | Reserved for | [This | | | Experimental Use | specification] | +------------------+-------------------------------+----------------+ | -32640 to -1 | Reserved for | [This | | | Private Use | specification] | +------------------+-------------------------------+----------------+ | 0 | Reserved | [This | | | | specification] | +------------------+-------------------------------+----------------+ | 1 | Security AAD | [This | | | Hashing | specification] | +------------------+-------------------------------+----------------+ | 2 | Preserve | [This | | | Extensions | specification] | +------------------+-------------------------------+----------------+ | 3 | Security | [This | | | Sourcing | specification] | +------------------+-------------------------------+----------------+ | 4 | Security | [This | | | Acceptance | specification] | +------------------+-------------------------------+----------------+ | 5 to 32767 | Unassigned | | +------------------+-------------------------------+----------------+ Table 2: Manifest Reason Codes Specifications of new metadata items and new block data items need to define the CBOR item structure of the map value as well as the interpretation of that value by entities processing the Manifest. Entities will ignore items with an unknown key, and that behavior needs to be considered by new specifications. IANA has created, under the "Bundle Protocol" registry group [IANA-BUNDLE], a registry titled "Manifest Metadata Items" and initialize it with the contents of Table 3. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA. Sipos Expires 20 January 2027 [Page 19] Internet-Draft BP Manifest July 2026 +===========+==============+=====================+================+ | Key | Name | Value Type | References | +===========+==============+=====================+================+ | -32768 to | Reserved for | | [This | | -32641 | Experimental | | specification] | | | Use | | | +-----------+--------------+---------------------+----------------+ | -32640 to | Reserved for | | [This | | -1 | Private Use | | specification] | +-----------+--------------+---------------------+----------------+ | 0 | Reserved | | [This | | | | | specification] | +-----------+--------------+---------------------+----------------+ | 2 | Manifest | embed-eid-structure | [This | | | Source | | specification] | +-----------+--------------+---------------------+----------------+ | 3 | Timestamp | dtn-time | [This | | | | | specification] | +-----------+--------------+---------------------+----------------+ | 4 to | Unassigned | | | | 32767 | | | | +-----------+--------------+---------------------+----------------+ Table 3: Manifest Metadata Items IANA has created, under the "Bundle Protocol" registry group [IANA-BUNDLE], a registry titled "Manifest Data Items" and initialize it with the contents of Table 4. For non-negative code points the registration procedure is Specification Required and the Block Type column is empty. For negative code points the registration procedure is Specification Required and the Block Type column references a type from the "Bundle Block Types" registry in the same group. Sipos Expires 20 January 2027 [Page 20] Internet-Draft BP Manifest July 2026 +=======+===========+==================+===========+================+ | Block | Key | Name | Value | References | | Type | | | Type | | +=======+===========+==================+===========+================+ | | 0 | Reserved | | [This | | | | | | specification] | +-------+-----------+------------------+-----------+----------------+ | | 2 | Block Flags | uint | [This | | | | | | specification] | +-------+-----------+------------------+-----------+----------------+ | | 5 | BTSD Length | uint | [This | | | | | | specification] | +-------+-----------+------------------+-----------+----------------+ | | 6 | BTSD Hash | btsd-hash | [This | | | | | | specification] | +-------+-----------+------------------+-----------+----------------+ | | 7 to | Unassigned | | | | | 31614 | | | | +-------+-----------+------------------+-----------+----------------+ | | 31615 to | Reserved for | | [This | | | 32639 | Private Use | | specification] | +-------+-----------+------------------+-----------+----------------+ | | 32640 to | Reserved for | | [This | | | 32767 | Experimental Use | | specification] | +-------+-----------+------------------+-----------+----------------+ | Block Type Specific items follow | +-------+-----------+------------------+-----------+----------------+ | 11,12 | -1 | Security Targets | array of | [This | | | | | uint | specification] | +-------+-----------+------------------+-----------+----------------+ | 11,12 | -2 | Security Context | int16 | [This | | | | ID | | specification] | +-------+-----------+------------------+-----------+----------------+ | 11,12 | -3 | Security Key ID | bstr | [This | | | | | | specification] | +-------+-----------+------------------+-----------+----------------+ | | -31616 | Reserved for | | [This | | | to | Private Use | | specification] | | | -32640 | | | | +-------+-----------+------------------+-----------+----------------+ | | -32641 | Reserved for | | [This | | | to | Experimental Use | | specification] | | | -32768 | | | | +-------+-----------+------------------+-----------+----------------+ Table 4: Manifest Data Items 8. References Sipos Expires 20 January 2027 [Page 21] Internet-Draft BP Manifest July 2026 8.1. Normative References [IANA-BUNDLE] IANA, "Bundle Protocol", . [IANA-COSE] IANA, "CBOR Object Signing and Encryption (COSE)", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . 8.2. Informative References [I-D.ietf-dtn-bpsec-cose] Sipos, B., "Bundle Protocol Security (BPSec) COSE Context", Work in Progress, Internet-Draft, draft-ietf- dtn-bpsec-cose-16, 3 June 2026, . Sipos Expires 20 January 2027 [Page 22] Internet-Draft BP Manifest July 2026 [I-D.ietf-dtn-eid-pattern] Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-09, 6 July 2026, . [I-D.tian-dtn-sbam] Dowling, B., Hale, B., Tian, X., and B. Wimalasiri, "Securing BPSec Against Arbitrary Packet Dropping", Work in Progress, Internet-Draft, draft-tian-dtn-sbam-05, 2 July 2026, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC9173] Birrane, III, E., White, A., and S. Heiner, "Default Security Contexts for Bundle Protocol Security (BPSec)", RFC 9173, DOI 10.17487/RFC9173, January 2022, . [RFC9995] Steele, O., Lasker, S., and H. Birkholz, "CBOR Object Signing and Encryption (COSE) Hash Envelope", RFC 9995, DOI 10.17487/RFC9995, July 2026, . Acknowledgments Author's Address Brian Sipos The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 United States of America Sipos Expires 20 January 2027 [Page 23] Internet-Draft BP Manifest July 2026 Email: brian.sipos+ietf@gmail.com Sipos Expires 20 January 2027 [Page 24]