| Internet-Draft | BPSec Acceptor Source Binding | October 2026 |
| Gupthaa | Expires 30 April 2027 | [Page] |
RFC 9172 Section 8.2.2 describes how a legitimate node can replace a source's Block Integrity Block (BIB) with one made under its own key, and how an acceptor that only checks that a BIB "was generated by a legitimate user" accepts the result. This document specifies the acceptor-side condition that prevents this substitution in deployments with per-source keys: each required security service on a target block is bound to the security source that is authoritative for that block, and is not satisfied by a block from any other source, even an authorized one. It also clarifies that the primary block is bound to a payload only through the integrity scope of the payload's own BIB, not through a separate BIB over the primary block.¶
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 30 April 2027.¶
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.¶
BPSec [RFC9172], the security extension to Bundle Protocol Version 7 [RFC9171], allows a bundle to carry security blocks from several security sources (Section 2.2) and leaves security policy to each deployment (Section 1.2). Section 8.2.2 names the insider substitution and recommends a source-side mitigation: the source adds a BIB and then a BCB over both the BIB and its target.¶
A formal analysis in the Tamarin prover, with machine-checked attack and fix models and a configuration checker for the HDTN and ION policy formats (artifact to be published; available on request), shows three things that this document turns into guidance:¶
An acceptor that binds each required service to the expected security source defeats the substitution for any path length and any set of compromised legitimate sources, using symmetric keys only.¶
The Section 8.2.2 mitigation does not remove the need for that binding: if the acceptor accepts a BCB from any authorized source, a legitimate node discards both blocks and re-secures a payload of its choice under its own BIB and BCB keys. Binding either the BCB or the inner BIB to the expected source suffices when keys are per source. When the BCB key is shared by all senders to a destination, binding the per-source BIB still suffices.¶
A BIB over the primary block that is separate from the payload's BIB protects the primary block but does not bind it to the payload: blocks of two genuine bundles from the same source can be combined. Only the primary-block bit in the payload BIB's own integrity scope flags ([RFC9173] Section 3.3.3) binds them.¶
Per-source keys and primary-block integrity scope are recommended for space DTNs by [MADOERY2024]; this document adds the acceptor-side condition that makes per-source binding sound, namely that the required service be bound to the expected source rather than, as is common, to the security source the received block itself names.¶
The key words "MUST", "MUST NOT", "SHOULD" and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
For every target block for which an acceptor's local policy requires a security service on a given flow:¶
R1 (source binding). The acceptor MUST record, per required service and per target block, the security source that is authoritative for that service on that block, and the key material bound to that source.¶
R2 (no substitution). The acceptor MUST NOT treat a BIB or BCB as satisfying the requirement unless it verifies under the key material recorded under R1. A block that verifies under the key of any other source, including one otherwise authorized in the deployment, MUST NOT satisfy the requirement. (The Security Source field of the ASB is an untrusted lookup hint; compare RFC 9172 erratum 8312.)¶
R3 (fail closed). If no block satisfying R2 is present, the acceptor MUST treat the target as failing its required service.¶
R4 (no privilege bleed). Authorization of a node to add security services for one purpose, such as re-securing at a gateway, MUST NOT make it the authoritative source under R1 for another source's block.¶
R5 (bundle binding). For a required payload-integrity service, the acceptor MUST require that the satisfying BIB has the primary-block bit (bit 0) set in its integrity scope flags ([RFC9173] Section 3.3.3), or omits the parameter so that the default of 7 applies. A separate BIB over the primary block MUST NOT be treated as satisfying this rule.¶
The BIB-then-BCB construction of RFC 9172 Section 8.2.2 protects the BIB inside the BCB, but an acceptor that accepts a BCB from any authorized source can be given a different BCB. R1 and R2 applied at either layer close this. Note that RFC 9172 Section 3.9, last paragraph, requires a source that wants both plaintext integrity and encryption of a target to use a BCB with an integrity result "instead of adding both a BIB and then a BCB for the security target at the security source". The rules above apply to either construction.¶
These rules assume per-source keys. Where a single key is shared by all nodes, RFC 9172 Section 8.1 already notes that a legitimate node is equivalent to a privileged node, and no acceptor rule over that key can tell the nodes apart. A privileged node (one holding the authoritative source's key) is out of scope, as it is in RFC 9172 and [I-D.tian-dtn-sbam]. A cryptographic analysis of BPSec is given in [DOWLING2025]; the present document addresses the orthogonal question of which acceptor policy compositions are safe.¶
This document has no IANA actions.¶
The author thanks the DTN Working Group for discussion of this topic.¶