



Delay/Disruption Tolerant Networking                          B. Dowling
Internet-Draft                                     King's College London
Intended status: Standards Track                                 B. Hale
Expires: 28 November 2026                                        X. Tian
                                               Naval Postgraduate School
                                                           B. Wimalasiri
                                                   King's College London
                                                             27 May 2026


            Securing BPSec Against Arbitrary Packet Dropping
                         draft-tian-dtn-sbam-04

Abstract

   In this document we describe Secure Bundle Protocol Audit Mechanism
   (SBAM), an authentication protocol designed to provide cryptographic
   auditing services for the Bundle Security protocol.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://bwimad.github.io/draft-xxx-str-bpsec/draft-tian-dtn-
   sbam.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-tian-dtn-sbam/.

   Discussion of this document takes place on the Delay/Disruption
   Tolerant Networking Working Group mailing list
   (mailto:[dtn@ietf.org](dtn@ietf.org)), which is archived at
   https://mailarchive.ietf.org/arch/browse/dtn/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bwimad/draft-xxx-str-bpsec.

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






Dowling, et al.         Expires 28 November 2026                [Page 1]

Internet-Draft                    SBAM                          May 2026


   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 28 November 2026.

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Motivation and Problem Statement  . . . . . . . . . . . .   6
   2.  Design Decisions  . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Block-Level Granularity . . . . . . . . . . . . . . . . .   7
     2.2.  Mixed Security Policy . . . . . . . . . . . . . . . . . .   7
     2.3.  User-Defined Security Contexts  . . . . . . . . . . . . .   8
     2.4.  Deterministic Processing  . . . . . . . . . . . . . . . .   8
     2.5.  COSE-Context Considerations . . . . . . . . . . . . . . .   8
     2.6.  Scope Flag  . . . . . . . . . . . . . . . . . . . . . . .   8
     2.7.  Security Blocks . . . . . . . . . . . . . . . . . . . . .   8
     2.8.  Block Definitions . . . . . . . . . . . . . . . . . . . .   9
   3.  SecureBPSec Audit Mechanism Protocol Overview . . . . . . . .   9
     3.1.  Unique Key Identifiers  . . . . . . . . . . . . . . . . .  10
     3.2.  Bundle Protocol Manifest Block  . . . . . . . . . . . . .  12
     3.3.  Audit Creation  . . . . . . . . . . . . . . . . . . . . .  14
     3.4.  Reporting . . . . . . . . . . . . . . . . . . . . . . . .  15
     3.5.  Verification  . . . . . . . . . . . . . . . . . . . . . .  16
     3.6.  Blocks Excluded by SBAM . . . . . . . . . . . . . . . . .  16
     3.7.  SBAM Integration with Manifest Block  . . . . . . . . . .  16
   4.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  19
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     5.1.  Trivial Block Removal . . . . . . . . . . . . . . . . . .  19
     5.2.  Insider Attack  . . . . . . . . . . . . . . . . . . . . .  19



Dowling, et al.         Expires 28 November 2026                [Page 2]

Internet-Draft                    SBAM                          May 2026


   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  New Registry: SBAM Security Context Parameters  . . . . .  19
     6.2.  Manifest Data Items Registry  . . . . . . . . . . . . . .  20
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   This document defines additional security features for the Bundle
   Protocol Security (BPSec) [RFC9172] and is intended in use for Delay
   Tolerant Networking (DTN) environments using BPSec to provide
   security guarantees, Secure Bundle Audit Mechanism (SBAM) is intended
   to provide additional security guarantees for BPSec communication
   between a bundle source acting as origin security source, any
   intermediate security acceptors, and a destination security acceptor
   also acting as the bundle destination.

   The BPSec specification [RFC9172] defines BPSec as "an end-to-end
   security service that operates in all of the environments where the
   BP operates" and claims to provide "integrity and confidentiality
   services for BP bundles".  In particular, BPSec enables partial
   processing of bundles, where an intermediate node acting as a
   security acceptor can process and remove security services.  As a
   result, it is possible for an intermediate malicious node to simply
   drop blocks along with any associated security operations attached to
   them.

   SBAM provides in-band cryptographic integrity guarantees between a
   bundle source and its destination while remaining consistent with the
   operational requirements of BPSec, which permit intermediate nodes to
   process and discard security blocks added by the bundle source.  At
   the same time, SBAM enables the destination node to detect
   adversarial modifications to security operations added to the bundle
   by the bundle source and to verify whether security service blocks
   added by the bundle source were maliciously dropped, processed, or
   modified during transit, while retaining compatibility with existing
   BPSec deployments.











Dowling, et al.         Expires 28 November 2026                [Page 3]

Internet-Draft                    SBAM                          May 2026


1.1.  Scope

   This document defines a new security service for the Bundle Protocol
   Security (BPSec) [RFC9172] and is intended in use for Delay Tolerant
   Networking (DTN) environments using BPSec to provide security
   guarantees.  Specifically, the Secure Bundle Audit Mechanism (SBAM)
   enables the cryptographic detection of unauthorized modifications to
   security operations added by the bundle source, which also acts as
   the security source for a destination node that accepts the bundle
   payload.  Explicitly, the end-to-end security guarantee provided by
   SBAM is limited to security operations inserted by a bundle source
   acting as the security source for a destination node that accepts the
   bundle payload.  Any security operations added to a bundle by
   security sources other than the bundle source are outside the scope
   of SBAM.  In particular, security operations added by security
   sources along the bundle path between the bundle source and the
   destination, following bundle creation and the addition of SBAM
   operations, are legitimate and independent and are not covered by
   SBAM.

1.2.  Notation

   This section defines terminology that either is unique to the BPSec
   or SBAM and is necessary for understanding the concepts defined in
   this specification.

   *  Bundle Destination: the Bundle Protocol Agent (BPA) that receives
      a bundle and delivers the payload of the bundle to an Application
      Agent.  Also, an endpoint comprising the node(s) at which the
      bundle is to be delivered.  The bundle destination acts as the
      security acceptor for every security target in every security
      block in every bundle it receives.

   *  Bundle Protocol Agent: a node component that offers the Bundle
      Protocol services and executes its procedures.

   *  Bundle Source: the BPA that originates a bundle.  Also, any node
      ID of the node of which the BPA is a component.

   *  Cipher Suite: a set of one or more algorithms providing integrity
      and/or confidentiality services.  Cipher suites may define user
      parameters (e.g., secret keys to use), but they do not provide
      values for those parameters.

   *  Destination Node: a security acceptor BPA that is the bundle
      destination and processes the bundle payload.





Dowling, et al.         Expires 28 November 2026                [Page 4]

Internet-Draft                    SBAM                          May 2026


   *  Forwarder: any BPA that transmits a bundle in DTN.  Also, any node
      ID of the node of which the BPA that sent the bundle on its most
      recent hop is a component.

   *  Intermediate Node: a security acceptor BPA that is not the bundle
      destination.

   *  Intermediate Receiver, Waypoint, or Next Hop: any BPA that
      receives a bundle from a forwarder that is not the bundle
      destination.  Also, any node ID of the node of which the BPA is a
      component.

   *  Path: the ordered sequence of nodes through which a bundle passes
      on its way from source to destination.  The path is not
      necessarily known in advance by the bundle or any BPAs in DTN.

   *  Security Acceptor: a BPA that processes and dispositions one or
      more security blocks in a bundle.  Security acceptors act as the
      endpoint of a security service represented in a security block.
      They remove the security blocks they act upon as part of
      processing and disposition.  Also, any node ID of the node of
      which the BPA is a component.

   *  Security Block: a BPSec extension block in a bundle.

   *  Security Context: the set of assumptions, algorithms,
      configurations, and policies used to implement security services.

   *  Security Operation: the application of a given security service to
      a security target, denoted as OP(security service, security
      target).  For example, OP(bcb-confidentiality, payload).  Every
      security operation in a bundle MUST be unique, meaning that a
      given security service can only be applied to a security target
      once in a bundle.  A security operation is implemented by a
      security block.

   *  Security Service: a process that gives some protection to a
      security target.  For example, the BPSec specification defines
      security services for plaintext integrity (bib-integrity) and
      authenticated plaintext confidentiality with additional
      authenticated data (bcb-confidentiality).  This SBAM specification
      defines security services for cryptographic auditing of security
      services added by the bundle source to the bundle destination.

   *  Security Source: a BPA that adds a security block to a bundle.
      Also, any node ID of the node of which the BPA is a component.





Dowling, et al.         Expires 28 November 2026                [Page 5]

Internet-Draft                    SBAM                          May 2026


   *  Security Target: the block within a bundle that receives a
      security service as part of a security operation.

   *  Security Verifier: a BPA that verifies the data integrity of one
      or more security blocks in a bundle.  Unlike security acceptors,
      security verifiers do not act as the endpoint of a security
      service, and they do not remove verified security blocks.  Also,
      any node ID of the node of which the BPA is a component.

   *  Source Node: A BPA that creates an initial bundle.

   *  *Audit Pair*: A logical pairing consisting of a Manifest Block and
      its corresponding BIB, created by the bundle source acting as the
      initial security source and verified only by the destination node
      acting as the final security acceptor.  The underlying Manifest
      Block records identifying data for each security operation added
      to the bundle by the bundle source.

   *  *Report Pair*: A logical pairing consisting of a Manifest Block
      and its corresponding BIB, created by an intermediate node that
      processed and discarded source-added blocks.  The underlying
      Manifest Block duplicates identifying data for each bundle
      source–added security operation that is processed and discarded by
      an intermediate security acceptor.

1.3.  Motivation and Problem Statement

   DTN recognizes an attacker with complete network access, affording
   them read/write access to bundles traversing the network.
   Eavesdropping, modification, topological, and injection attacks are
   all described in [RFC9172], Section 8.2.  Therein, these "on-path
   attackers" can be unprivileged, legitimate, or privileged nodes
   depending on their access to cryptographic material: unprivileged
   nodes only have access to publicly shared information, legitimate
   nodes have additional access to keys provisioned for itself, and
   privileged nodes have further access to keys (privately) provisioned
   for others.  There are currently no guarantees against privileged
   attacks.













Dowling, et al.         Expires 28 November 2026                [Page 6]

Internet-Draft                    SBAM                          May 2026


   In an effort to distinguish malice by intermediate nodes, these
   classes can be further abstracted into honest security acceptors and
   dishonest forwarders.  Honest forwarders are privileged nodes that
   faithfully execute the role of a BPA as described in [RFC9171],
   Section 3.  Dishonest forwarders are unprivileged nodes that attempt
   to violate the integrity or confidentiality of blocks it processes
   (e.g. by dropping or modifying blocks).  Under its default security
   context [RFC9173], BPSec currently provides no cryptographic auditing
   mechanism that enables a destination node to detect adversarial
   modifications to security services added to a bundle by the bundle
   source.

   SBAM addresses this security gap by providing a mechanism that allows
   a bundle source, acting as the initial security source, to create a
   verifiable record of all security operations added to the bundle at
   origin, which is intended to be verified only by the final bundle
   destination.  At the same time, SBAM preserves the default behavior
   of BPSec, allowing intermediate nodes to process and discard security
   operations added by the bundle source, provided they attach a
   verifiable record that duplicates the identifying data for each
   discarded security operation, which will subsequently be verified by
   the bundle destination.

2.  Design Decisions

   In this section we describe the design decisions of BPSec [RFC9172],
   and describe how these are impacted through the use of SBAM.

2.1.  Block-Level Granularity

   SBAM design does not impact the block-level granularity of BPSec.
   SBAM provides a verifiable audit trail between source and destination
   nodes, for all security blocks added by the source node, while also
   allowing intermediaries to process and discard source-added blocks.

2.2.  Mixed Security Policy

   SBAM design does not impact the mixed security policy of BPSec.  SBAM
   design provides an additional layer of security between the source
   and destination nodes, by providing a mechanism for verifying that
   all security blocks added by the source node have either been
   processed by an authorized intermediary, or received by the
   destination node.  This functionality does not interfere with the
   ability of additional security sources (that are not the bundle
   source) to create/modify/process security blocks within the bundle.






Dowling, et al.         Expires 28 November 2026                [Page 7]

Internet-Draft                    SBAM                          May 2026


2.3.  User-Defined Security Contexts

   SBAM design does not impact the ability to implement user-defined
   security contexts within BPSec.  Users may select from registered
   security contexts and customize those contexts through security
   context parameters.

2.4.  Deterministic Processing

   SBAM design preserves and adheres to the deterministic processing
   requirements described in [RFC9172].

2.5.  COSE-Context Considerations

   In conjunction with a proper PKI mechanism, SBAM may be used in the
   COSE-Context [draft-ietf-dtn-bpsec-cose] to provide further
   authentication enhancements to auditing.  Specifically, through the
   use of digital signature algorithms rather than message
   authentication codes as described herein, SBAM in the COSE-context
   adds source authentication as well as authentication of intermediate
   nodes.

2.6.  Scope Flag

   The Integrity Security Context BIB_HMAC-SHA2 includes Integrity Scope
   Flags as a parameter set (see 3.2 and 3.3.3 in [RFC9173]).  The value
   of the Integrity Scope Flag describes what information is used to
   construct the Integrity Protected Plain Text (IPPT) for a BIB.  The
   existing Integrity Scope Flags in bit 2 and bit 3 refer to an
   excessive amount of information (block type code, block number, block
   processing control flags).  Since we explicitly only use the block
   number in our calculations, this scope flag is redundant and we
   choose to remove it.

2.7.  Security Blocks

   In this section we describe the different Security Blocks used in
   BPSec and SBAM.  In particular, we note that BPSec introduced two
   types of security blocks: the Block Integrity Block (BIB) and the
   Block Confidentiality Block (BCB) providing integrity and
   confidentiality and integrity, respectively.

   In SBAM we also introduce the audit-pair logical block and the
   report-pair logical block, which (when combined) enable security
   acceptors to verify only honest intermediate security acceptors have
   processed and discarded BIB or BCBs added to a bundle at origin.





Dowling, et al.         Expires 28 November 2026                [Page 8]

Internet-Draft                    SBAM                          May 2026


2.8.  Block Definitions

   The BPSec specification defines two types of security blocks: the
   Block Integrity Block (BIB) and the Block Confidentiality Block
   (BCB).  The SBAM specification defines two additional types of
   logical blocks; the audit-pair and report-pair operations.

   *  The BIB is used to ensure the integrity of its plaintext security
      target(s).  The integrity information in the BIB MAY be verified
      by any node along the bundle path from the BIB security source to
      the bundle destination.  Waypoints add or remove BIBs from bundles
      in accordance with their security policy.  BIBs are never used for
      integrity protection of the ciphertext provided by a BCB.  Because
      security policy at BPSec nodes may differ regarding integrity
      verification, BIBs do not guarantee hop-by-hop authentication, as
      discussed in Section 1.1 (https://www.rfc-editor.org/rfc/
      rfc9172.html#sup_sec_svc).

   *  The BCB indicates that the security target or targets have been
      encrypted at the BCB security source in order to protect their
      content while in transit.  As a matter of security policy, the BCB
      is decrypted by security acceptor nodes in the network, up to and
      including the bundle destination.  BCBs additionally provide
      integrity-protection mechanisms for the ciphertext they generate.

3.  SecureBPSec Audit Mechanism Protocol Overview

   The core guarantee provided by SBAM is a guarantee that, after
   correctly verifying audit-pair and report-pair security operations,
   the destination node is assured that either

   *  all security blocks added by the bundle source have arrived
      without an unprivileged node dropping or modifying them; or

   *  an honest intermediary has processed and discarded security block/
      s added by the bundle source.

   Thus, for any bundle, its source node also acting as initial security
   source, will generate security blocks for their destination node
   exactly as specified in BPSec [RFC9172].  Additionally, the source
   node will create a logical audit-pair block, which provides a
   cryptographically-authenticated record of all security services it
   provided for the bundle, as well as all necessary uniquely
   identifying information for each security operation, such as its key
   and block identifiers.






Dowling, et al.         Expires 28 November 2026                [Page 9]

Internet-Draft                    SBAM                          May 2026


   SBAM further specifies that any honest intermediary node that
   processes a security block created by the bundle source also provides
   a cryptographic proof that it was authorized to perform this
   operation.  This is achieved by replacing the processed and discarded
   security operation with a report-pair logical block that duplicates
   and authenticates, to the destination node (the final security
   acceptor), the uniquely identifying information associated with the
   discarded security service contained in the security block.  The SBAM
   report-pair therefore provides a cryptographically authenticated
   digest of the uniquely identifying information of the security block
   it processes, such as key and block identifiers.  This allows the
   relevant identifying information of a bundle source–added security
   operation to remain verifiable by the final security acceptor even
   after the original security block has been processed and discarded.

   Upon receiving the bundle, the destination node first verifies the
   audit-pair to validate its authenticity.  It then verifies each
   report-pair to confirm that it was added by an honest intermediary
   node.  The destination node subsequently collates the identifying
   information contained in the audit-pair and compares it with the
   identifying information collated from the report-pair blocks.
   Successful verification at each stage enables the destination node to
   confirm that no unprivileged node modified or removed any bundle
   source–added security operation during transit between the source and
   destination nodes.

3.1.  Unique Key Identifiers

   The Bundle Protocol Security (BPSec) and its defined security
   contexts, as described in [RFC9172] and [RFC9173] respectively, rely
   on the assumption that local security policies will inform Bundle
   Protocol Agents (BPAs) of the appropriate cryptographic keys to use
   for each security context.  This decentralized, policy-driven
   approach allows flexibility but introduces ambiguity when these
   policies are not uniformly enforced or clearly defined across
   participating nodes.  In the absence of standardized key selection
   mechanisms, there is a risk that different BPAs may select
   conflicting keys for the same security context or inadvertently reuse
   keys across incompatible contexts.  Such ambiguity can lead to key
   collisions, where multiple security contexts reference the same key
   identifier or cryptographic material unintentionally, undermining the
   security operations BPSec is intended to enforce.  To mitigate this
   ambiguity, SBAM introduces key-id as an explicit security context
   parameter, enabling BPAs to uniquely identify the correct
   cryptographic key for each security operation.






Dowling, et al.         Expires 28 November 2026               [Page 10]

Internet-Draft                    SBAM                          May 2026


   Key identifiers are always represented as a CBOR unsigned integer, in
   accordance with the parameter identification requirements of
   Section 3.10 of [RFC9172].  Key identifiers MUST be unique across all
   security operations within a given bundle and MUST distinctly
   identify a cryptographic key used for a given security operation
   within its security context.

   Within the SBAM design, three independent use cases for key-id are
   identified.  When combined, these use cases enable the establishment
   of a reciprocal trust relationship between the bundle source acting
   as the initial security source, privileged intermediary nodes, and
   the bundle destination acting as the final security acceptor.  The
   three distinct but interconnected key-id use cases are as follows:

   *  key-id for BPSec security services: This identifier uniquely
      identifies the key used by the bundle source to provide a BPSec
      integrity or confidentiality service (BIB and BCB respectively, as
      defined in [RFC9172]) when the bundle is created at origin.  This
      identifier MUST be carried as security context parameter TBA1 (see
      IANA Considerations (Section 6)) within the Security Context
      Parameters field of the Abstract Security Block (ASB) structure
      defined in Section 3.6 of [RFC9172], for every BIB and BCB within
      an SBAM bundle.  Each BPSec security operation MUST have a
      corresponding unique key-id to facilitate SBAM integration.

   *  key-id for auditing: This identifier uniquely identifies the key
      used by the bundle source to authenticate the audit-pair logical
      block to the bundle destination.  The audit-pair contains the
      uniquely identifying information for each security operation added
      to the bundle at origin, including the corresponding security
      service key-id values.  This identifier MUST be carried as
      security context parameter TBA1 (see IANA Considerations
      (Section 6)) within the ASB of the BIB authenticating the audit-
      pair manifest block, and MUST be independent of the security
      service key-id values recorded within the manifest itself.

   *  key-id for reporting: This identifier uniquely identifies the key
      used by a privileged intermediary node to authenticate the report-
      pair logical block to the bundle destination.  The report-pair
      duplicates the uniquely identifying information for each bundle
      source-added security operation (including the corresponding
      security service key-id values) that the intermediary processes
      and discards.  This identifier MUST be carried as security context
      parameter TBA1 (see IANA Considerations (Section 6)) within the
      ASB of the BIB authenticating the report-pair manifest block, and
      MUST be independent of both the security service key-id values
      recorded within the manifest and the key-id used for auditing.




Dowling, et al.         Expires 28 November 2026               [Page 11]

Internet-Draft                    SBAM                          May 2026


   In addition to its presence in the ASB of every BIB and BCB, the key-
   id associated with each covered security operation MUST also be
   recorded as map key -3 in the corresponding blockdata-map of every
   SBAM audit-pair and report-pair manifest block.  This duplicate
   record enables the destination node to correlate the identifying
   information in the manifest against the security operations it
   received or that were reported as processed by an intermediary.

   The use of these distinct key-id roles enables SBAM to bind the
   integrity of each bundle source-added BPSec security operation (via
   its associated security service key-id) to the key-id used to
   authenticate the audit-pair.  Upon successful verification, the
   destination node can confirm that the integrity of the BPSec security
   operations added at the bundle origin has been preserved.

   Independently, privileged intermediary nodes bind the report-pair
   key-id to the uniquely identifying information of each corresponding
   security service key-id associated with a bundle source-added
   security block that they process and discard.  This enables the
   destination node to verify that any modification to bundle source-
   added security operations was performed by a legitimate intermediary
   node.

   The management of key-id values, including how trust in them is
   established, maintained, and escrowed, is determined at the policy
   level and is outside the scope of this document.

3.2.  Bundle Protocol Manifest Block

   The Bundle Protocol Manifest Block introduced in
   [sipos-dtn-manifest-block] defines a new structured block type for
   BPv7 bundles.  A primary purpose of the Manifest Block is to provide
   a structured and auditable mechanism for maintaining a record of
   bundle security components between the bundle source, acting also as
   the security source, and the intended destination node.  This
   mechanism allows honest intermediary nodes to act as legitimate
   security acceptors, enabling them to process, and discard security
   blocks added by the source node while preserving an auditable record
   of those security-related components within the proposed manifest
   structure.  Manifest blocks enable the enumeration and identification
   of elements within a bundle in a consistent and machine-processable
   manner.  While manifest blocks are not defined as security-specific
   mechanisms in itself, they provide a structured representation of
   bundle content that can be used by such security mechanisms as SBAM.

   By listing covered components and associated metadata, manifest
   blocks create an environment in which integrity protection and
   authentication operations can be applied in a systematic way.  In



Dowling, et al.         Expires 28 November 2026               [Page 12]

Internet-Draft                    SBAM                          May 2026


   this sense, manifest blocks do not directly perform security
   functions, but it enables and supports such functions by supplying a
   well-defined container for describing and referencing BPSec bundle
   elements.

   Below is a diagram of the proposed Manifest Block structure as
   defined in [sipos-dtn-manifest-block].

   ; ---- General Manifest Block structure ----
   ; From sipos-dtn-manifest-block

   ; Type aliases
   block-id = [
     ; From the IANA Bundle Block Types registry
     block-type: uint,
     block-num:  uint,
   ]
   btsd-len      = uint
   btsd-hash     = (
     ; From the IANA COSE Algorithms registry
     alg:   tstr / int,
     value: bstr
   )
   bpsec-targets = [+ uint]

   $$metadata-item //= (
     0: int16
     ; Reason code from the Manifest Reason Codes registry
     2: embed-eid-structure
     3: dtn-time
   )

   $$blockdata-item //= (
     1:  block-id
     2:  block-control-flags
     5:  btsd-len
     6:  [+ btsd-hash]
     -1: bpsec-targets
     ; keys -1 and -2 apply only to BPSec security blocks (types 11, 12)
     -2: int16
     ; bpsec-security-context
   )

                     Figure 1: Manifest Block structure







Dowling, et al.         Expires 28 November 2026               [Page 13]

Internet-Draft                    SBAM                          May 2026


   SBAM leverages and extends the proposed Manifest Block structure to
   provide a verifiable audit trail between the source node and the
   destination node.  Manifest blocks enable SBAM functionality in two
   ways:

   (1) they define an object type for the audit-pair operation between
   the bundle source and the final security-acceptor destination node;
   and

   (2) they define an object type for the report-pair operation, which
   supports intermediary processing of source–generated security blocks
   while preserving the associated original audit information.

   Together, these two object types establish a verifiable audit trail
   between the bundle source and its destination node.  This audit trail
   preserves the BPSec-defined behavior that permits intermediary nodes
   to process and discard security blocks as required, while also
   providing a mechanism to detect any unauthorized modification to the
   security operations of a bundle enforced by its source.

3.3.  Audit Creation

   The audit creation process is described in detail in the following
   sections.

   At the time of bundle creation, the source node SHALL generate a
   verifiable audit-pair logical block that covers all security
   operations added by the source node.  Structurally, an audit-pair
   consists of a manifest block that records all security operations
   added to a bundle by its originator, and a BIB that authenticates the
   manifest contents.

   The audit-pair SHALL contain all relevant identifying information for
   each relevant security block (represented by independent manifest
   block-data-map), which SHALL include at minimum the identity of the
   security block block-id, information about its security context
   including a unique key-id, a list of target block identifiers
   security-targets to which the security block operation applies, and
   the payload (encoded in btsd-hash) of the bundle.  This audit-pair
   SHALL then be cryptographically authenticated by a BIB generated by
   the source node which computes a cryptographic MAC over the audit-
   pair using a unique audit-pair operation key shared with the
   destination node.  The key-id for the BIB authenticating the audit-
   pair SHALL be included in the BIB security context and SHALL be
   independent of the security context information contained in the
   associated manifest block.





Dowling, et al.         Expires 28 November 2026               [Page 14]

Internet-Draft                    SBAM                          May 2026


   The destination node SHALL discard any audit-pair (along with any
   source-generated payload intended for it) that is not
   cryptographically verified by a BIB generated by the source node.  A
   further flag MAY be added to the audit-pair and its BIB to indicate
   that it is expected only to be verified by the intended bundle
   destination security acceptor.

   The uniquely identifying information associated with the BIB that
   authenticates the audit-pair MUST NOT be included in the audit-pair
   record, as this would introduce a circular verification dependency.

   See SBAM Integration with Manifest Block (Section 3.7) for more
   details on audit-pair design specifications.

3.4.  Reporting

   The reporting process is described in detail in the following
   sections.

   Any security accepting intermediary that processes an SBAM bundle
   security operation added by the bundle source SHALL replace the
   processed operation with a report-pair operation.  Structurally, a
   report-pair consists of a manifest block, and a BIB that
   authenticates the manifest contents.

   The report-pair SHALL contain all relevant identifying information
   for each security block processed and discarded by the intermediary
   along the bundle path.  Such report-pair SHALL include at minimum the
   identity of the security block (block-id) processed, a duplicate
   record of its security context (including its unique security service
   key-id) and a duplicate record of the security targets to which the
   security block operation applies.  This report-pair SHALL then be
   cryptographically authenticated by a BIB generated over the manifest
   which computes a cryptographic MAC over the manifest block-data-map
   using a unique report-pair operation key the processing intermediary
   shares with the destination node.  The key-id for the BIB
   authenticating the report-pair SHALL be included in the BIB security
   context and SHALL be independent of the security context information
   contained in the associated manifest block.

   A further flag MAY be added to the report-pair to indicate that it is
   expected only to be verified by the intended destination security
   acceptor.

   The uniquely identifying information associated with the BIB that
   authenticates the report-pair MUST NOT be included in the report-pair
   record, as this would introduce a circular verification dependency.




Dowling, et al.         Expires 28 November 2026               [Page 15]

Internet-Draft                    SBAM                          May 2026


   See SBAM Integration with Manifest Block (Section 3.7) for more
   details on the report-pair design specifications.

3.5.  Verification

   The verification process is described in detail in the following
   sections.

   When the destination node receives an SBAM bundle, it SHALL verify
   that the audit-pair and report-pair(s) it received can be
   cryptographically authenticated before accepting the bundle as valid.
   An SBAM bundle SHALL be considered valid by accepting destination
   node only if the following conditions are met:

   1.  The audit-pair is cryptographically verified by the attached BIB
       generated by the source node.  Failure indicates tampering or
       corruption of the bundle or associated block-type-specific-data.

   2.  Each report-pair generated by an intermediary along the bundle
       path is cryptographically verified by its associated BIB.  This
       enables the destination node to validate that the corresponding
       discarded bundle source-added security operation, which the
       report-pair replaced, was processed by an authorized intermediary
       and that the original security configuration of that operation
       remains cryptographically verifiable.

   3.  The block-type-specific-data of the audit-pair manifest block
       matches a concatenation of blockdata-item(s) for each report-pair
       manifest block.

3.6.  Blocks Excluded by SBAM

   SBAM participants should exclude blocks that necessarily change
   throughout a bundle's life cycle from auditing.  Extension blocks
   such as Hop-Count or Previous Node which change values SHOULD be
   excluded from SBAM protection to avoid unnecessary processing and
   overhead.

3.7.  SBAM Integration with Manifest Block

   Instead of defining a separate extension block, the SBAM can be
   integrated within the proposed Manifest Block structure.  This
   approach leverages the existing manifest framework and would involve
   minor modifications or extensions to the Manifest Block fields
   currently defined in [sipos-dtn-manifest-block] to accommodate SBAM
   audit data.





Dowling, et al.         Expires 28 November 2026               [Page 16]

Internet-Draft                    SBAM                          May 2026


   When a manifest block is used as part of an audit-pair (see Audit
   Creation (Section 3.3)), the _reason_ item of the meta-data-map SHALL
   be set to security-sourcing.  The resulting manifest-block SHALL then
   act as the security-target of a further BIB block which authenticates
   its content.  This manifest block and its associated BIB block are
   generated by the initial bundle source and together form the logical
   unit referred to as an audit-pair.  A further flag MAY be added to
   the audit-pair to indicate that it is expected only to be verified by
   the intended destination security acceptor.  The BIB SHALL be
   generated by the original source node and SHALL contain a
   cryptographic MAC over its associated manifest block using a unique
   audit-pair operation key shared with the destination node.
   Furthermore, an additional item that identifies the cryptographic key
   used for the corresponding cryptographic operation, key-id, SHALL be
   added to the audit-pair when used for SBAM auditing.

   ; ---- Audit-pair manifest block structure ----
   ; Reason: security-sourcing (code 3)
   ; Created by bundle source, covers all source-added security blocks.

   $$metadata-item //= (
   0: int16
   ; reason = 3 (security-sourcing)
   2: embed-eid-structure
   3: dtn-time
   )
   ; One blockdata-item per source-generated security operation
   $$blockdata-item //= (
   1:  block-id
   2:  block-control-flags
   5:  btsd-len
   6:  [+ btsd-hash]
   -1: bpsec-targets
   -2: int16
   ; bpsec-security-context
   -3: key-id
   ; key-id of the covered security operation, CBOR unsigned integer
   )

       Figure 2: Manifest Block structure adapted to facilitate SBAM
                                  auditing

   When a manifest block is used as part of a report-pair, the _reason_
   item of the meta-data-map SHALL be set to security-acceptance.  This
   report-pair is generated every time an intermediary acceptor
   processes a bundle source-generated security block.  The resulting
   manifest-block SHALL then act as the security-target of a further BIB
   block which authenticates its content.  This manifest block and its



Dowling, et al.         Expires 28 November 2026               [Page 17]

Internet-Draft                    SBAM                          May 2026


   associated BIB block are generated by the SBAM-processing
   intermediary and together form the logical unit referred to as an
   report-pair.  A further flag MAY be added to the report-pair to
   indicate that it is expected only to be verified by the intended
   destination security acceptor.

   Furthermore, an additional item that identifies the cryptographic key
   used for the corresponding cryptographic operation, key-id, SHALL be
   added to the report-pair when used for SBAM reporting.  This enables
   an intermediary security acceptor that processes a source-generated
   security block to append a verifiable record of the processed
   security-block-specific-data for use by the intended destination
   security acceptor.  The btsd-len and btsd-hash fields in the manifest
   block do not serve a functional purpose within a report-pair and as
   such MAY be excluded without any functional impact.

   This hop-by-hop generated report-pair SHALL subsequently be used by
   the intended destination security acceptor to verify the integrity of
   the received bundle.

; ---- Report-pair manifest block structure ----
; Reason: security-acceptance (code 4)
; Created by intermediary acceptor per discarded source-added operation.
; btsd-len (5) and btsd-hash (6) omitted per SBAM Section 3.7.

$$metadata-item //= (
  0: int16
  ; reason = 4 (security-acceptance)
  2: embed-eid-structure
  3: dtn-time
)

$$blockdata-item //= (
  1:  block-id
  2:  block-control-flags
  -1: bpsec-targets
  -2: int16
  ; bpsec-security-context
  -3: key-id
  ; key-id of the discarded security operation
)

    Figure 3: Manifest Block structure adapted to facilitate SBAM
                              reporting







Dowling, et al.         Expires 28 November 2026               [Page 18]

Internet-Draft                    SBAM                          May 2026


4.  Processing Rules

   *  *source-node*: Adds audit-pair consisting of a manifest block
      along with its verifying BIB after other security blocks and
      before payload.

   *  *intermediate-node*: Processes BIB/BCB, adds report-pairconsisting
      of a manifest block along with its verifying BIB.

   *  *destination-node*: Validates all block-data-items within audit-
      pair and all report-pair(s), and checks whether the block-type-
      specific-data of the audit-pair manifest matches a concatenation
      of all block-type-specific-data for each report-pair manifest,
      prior to accepting payload.  If any validation fails, the bundle
      MUST be discarded.

5.  Security Considerations

5.1.  Trivial Block Removal

   SBAM allows for the detection of unauthorized deletion of source-
   added BIB/BCB.  This requires that the intended recipient performing
   the SBAM verifications described in Section 3.5 to avoid a trivial
   attack by a malicious intermediary of simply removing all security
   blocks.

5.2.  Insider Attack

   SBAM protected bundles are still vulnerable to *privileged insider*
   attacks unless asymmetric crypto is introduced.  Malicious nodes with
   privileged access to keys associated with protected blocks may be
   able to modify SBAM block values undetected (e.g. forge or overwrite
   report-pair).

6.  IANA Considerations

6.1.  New Registry: SBAM Security Context Parameters

   IANA is requested to create, under the "Bundle Protocol" registry
   group [IANA-BUNDLE], a new registry titled "SBAM Security Context
   Parameters".

   The registration policy for this registry is Specification Required
   [RFC8126].  The value range is unsigned integer.

   This registry defines parameters that MUST be supported by any
   security context used within an SBAM bundle, in addition to
   parameters defined by that security context's own specification.



Dowling, et al.         Expires 28 November 2026               [Page 19]

Internet-Draft                    SBAM                          May 2026


   Each parameter is identified by an unsigned integer and applies to
   the Security Context Parameters field of the Abstract Security Block
   (ASB) structure defined in Section 3.6 of [RFC9172], for both Block
   Integrity Blocks (BIB) and Block Confidentiality Blocks (BCB) within
   an SBAM bundle.

   IANA is requested to initialize this registry with the following
   entry:

   +=========+===========+====================+=======+===============+
   | Parm Id | Parm Name | CBOR Encoding Type | Block | References    |
   |         |           |                    | Types |               |
   +=========+===========+====================+=======+===============+
   | TBA1    | BPSec Key | unsigned integer   | 11,   | This          |
   |         | ID        |                    | 12    | specification |
   +---------+-----------+--------------------+-------+---------------+

                Table 1: SBAM Security Context Parameters

      RFC EDITOR: Replace TBA1 with the value assigned by IANA and
      remove this note prior to publication.

   The BPSec Key ID parameter (Parm Id TBA1) uniquely identifies the
   cryptographic key used for the security operation represented by the
   enclosing BIB or BCB.  Its presence is REQUIRED in every BIB and BCB
   within an SBAM bundle, as defined in Section 3.1 of this document.
   The value MUST be encoded as a CBOR unsigned integer and MUST be
   unique across all security operations within a given bundle.

   Each security context used within an SBAM bundle MUST define how this
   parameter is encoded and interpreted within its ASB, in accordance
   with the parameter identification requirements of Section 3.10 of
   [RFC9172].  The specific encoding is defined by the security context
   specification; the semantic meaning is defined here.

6.2.  Manifest Data Items Registry

   This document requests registration of one new block data item in the
   "Manifest Data Items" registry under the "Bundle Protocol" registry
   group [IANA-BUNDLE], as defined in [sipos-dtn-manifest-block]:











Dowling, et al.         Expires 28 November 2026               [Page 20]

Internet-Draft                    SBAM                          May 2026


   +============+=====+==============+============+====================+
   | Block Type | Key | Name         | Value Type | References         |
   +============+=====+==============+============+====================+
   | 11, 12     | -3  | BPSec Key ID | uint       | This               |
   |            |     |              |            | specification      |
   +------------+-----+--------------+------------+--------------------+

                Table 2: Manifest Data Items Registry Entry

      RFC EDITOR: Confirm that key -3 is unassigned in the Manifest Data
      Items registry at time of publication and remove this note.

   The Block Type column specifies both 11 (Block Integrity Block) and
   12 (Block Confidentiality Block) as defined in [RFC9172], since the
   key-id item applies when the covered block provides either an
   integrity or a confidentiality service.

7.  References

7.1.  Normative References

   [IANA-BUNDLE]
              "IANA, Bundle Protocol", n.d.,
              <https://www.iana.org/assignments/bundle/>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/rfc/rfc2104>.

   [RFC2119]  Bradner, S. O., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March
              1997, <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and D. T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", RFC 8126,
              DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
              Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022,
              <https://www.rfc-editor.org/info/rfc9171>.

   [RFC9172]  Birrane, E. and K. Fall, "Bundle Protocol Security
              (BPSEC)", RFC 9172, DOI 10.17487/RFC9172, January 2022,
              <https://www.rfc-editor.org/info/rfc9172>.





Dowling, et al.         Expires 28 November 2026               [Page 21]

Internet-Draft                    SBAM                          May 2026


   [RFC9173]  Birrane, E., "Bundle Protocol Security (BPSEC) Default
              Security Contexts", RFC 9173, DOI 10.17487/RFC9173,
              January 2022, <https://www.rfc-editor.org/info/rfc9173>.

7.2.  Informative References

   [CryptoRocket]
              "Cryptography is Rocket Science", n.d.,
              <https://doi.org/10.62056/a39qudhdj>.

   [draft-ietf-dtn-bpsec-cose]
              Sipos, B., "Bundle Protocol Security (BPSec) COSE
              Context", 3 June 2025, <https://datatracker.ietf.org/doc/
              draft-ietf-dtn-bpsec-cose/>.

   [sipos-dtn-manifest-block]
              Sipos, B., "Bundle Protocol (BP) Manifest Block", 29
              December 2025, <https://datatracker.ietf.org/doc/html/
              draft-sipos-dtn-manifest-block-00>.

Appendix A.  Example

   This appendix is informative.

   This appendix presents a series of examples of constructing SBAM
   logical blocks using manifest blocks defined in
   [sipos-dtn-manifest-block] and bundle integrity blocks defined in
   [RFC9172].

   ; ---- Shared manifest structure ----
   ; From sipos-dtn-manifest-block

   manifest-structure = { * int16 => any }
   int16 = -32768 .. 32767
   metadata-map  = {* $$metadata-item  } .within manifest-structure
   blockdata-map = {* $$blockdata-item } .within manifest-structure

   ext-data-manifest = [
     metadata-map,
     [* blockdata-map]
   ]

   block-id      = [ block-type: uint, block-num: uint ]
   btsd-len      = uint
   btsd-hash     = ( alg: tstr / int, value: bstr )
   bpsec-targets = [+ uint]
   bpsec-key-id  = uint
   ; bpsec-key-id: CBOR unsigned integer, per SBAM Section 3.1



Dowling, et al.         Expires 28 November 2026               [Page 22]

Internet-Draft                    SBAM                          May 2026


   ; ---- Audit-pair manifest (reason: security-sourcing, code 3) ----
   ; Created by bundle source, covers all source-added security blocks.

   $$metadata-item //= (
     0: int16
     ; reason = 3 (security-sourcing)
     2: embed-eid-structure
     3: dtn-time
   )

   $$blockdata-item //= (
     1:  block-id
     2:  block-control-flags
     5:  btsd-len
     6:  [+ btsd-hash]
     -1: bpsec-targets
     -2: int16
     ; bpsec-security-context
     -3: key-id
     ; key-id for the covered security operation
   )

   ; ---- Report-pair manifest (reason: security-acceptance, code 4) ----
   ; Created by intermediary acceptor per discarded source-added security operation..

   $$metadata-item //= (
     0: int16
     ; reason = 4 (security-acceptance)
     2: embed-eid-structure
     3: dtn-time
   )

   $$blockdata-item //= (
     1:  block-id
     2:  block-control-flags
     -1: bpsec-targets
     -2: int16
     ; bpsec-security-context
     -3: key-id
     ; key-id of the discarded security operation
   )

   ; ---- BIB authenticating either manifest (shared structure) ----
   ; Per RFC 9172 Section 3.6

   abstract-security-block = [
     security-targets:       [+ uint]
     security-context-id:    uint



Dowling, et al.         Expires 28 November 2026               [Page 23]

Internet-Draft                    SBAM                          May 2026


     security-context-flags: uint
     security-source:        eid-structure
     security-parameters:    [* security-parameter]
     security-results:       [* [* security-result]]
   ]

   security-parameter = [ parm-id: uint, parm-value: any ]
   security-result    = [ result-id: uint, result-value: any ]

   bib-block = [
     block-type:  11
     block-num:   uint
     block-flags: uint
     crc-type:    0 / 1 / 2
     data:        bstr .cbor abstract-security-block
   ]

Authors' Addresses

   Benjamin Dowling
   King's College London
   Email: benjamin.dowling@kcl.ac.uk


   Britta Hale
   Naval Postgraduate School
   Email: britta.hale@nps.edu


   Xisen Tian
   Naval Postgraduate School
   Email: xisen.tian1@nps.edu


   Bhagya Wimalasiri
   King's College London
   Email: bhagya.wimalasiri@kcl.ac.uk














Dowling, et al.         Expires 28 November 2026               [Page 24]
