Acceptor Source Binding for Bundle Protocol Security (BPSec)
draft-gupthaa-dtn-bpsec-source-binding-00

Delay/Disruption Tolerant Networking                    N. D. S. Gupthaa
Internet-Draft                                           27 October 2026
Intended status: Informational                                          
Expires: 30 April 2027

      Acceptor Source Binding for Bundle Protocol Security (BPSec)
               draft-gupthaa-dtn-bpsec-source-binding-00

Abstract

   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.

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 30 April 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.

Gupthaa                   Expires 30 April 2027                 [Page 1]
Internet-Draft        BPSec Acceptor Source Binding         October 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Acceptor Rules  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Relation to the Section 8.2.2 Mitigation  . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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:

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

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

Gupthaa                   Expires 30 April 2027                 [Page 2]
Internet-Draft        BPSec Acceptor Source Binding         October 2026

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

2.  Acceptor Rules

   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.

Gupthaa                   Expires 30 April 2027                 [Page 3]
Internet-Draft        BPSec Acceptor Source Binding         October 2026

3.  Relation to the Section 8.2.2 Mitigation

   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.

4.  Security Considerations

   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.

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

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

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

   [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,
              <https://www.rfc-editor.org/info/rfc9173>.

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

Gupthaa                   Expires 30 April 2027                 [Page 4]
Internet-Draft        BPSec Acceptor Source Binding         October 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

   [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, <https://datatracker.ietf.org/doc/html/draft-
              tian-dtn-sbam-05>.

   [DOWLING2025]
              Dowling, B., Hale, B., Tian, X., and B. Wimalasiri,
              "Cryptography is Rocket Science: Analysis of BPSec",
              DOI 10.62056/a39qudhdj, 2025,
              <https://doi.org/10.62056/a39qudhdj>.

   [MADOERY2024]
              Madoery, P. G., Cherini, R., Cammarano, A., Grosso, J.,
              and J. M. Finochietto, "Bundle Protocol Security Models
              and Policies for Safeguarding Space Information Networks",
              IEEE Journal of Radio Frequency Identification 8:547-558,
              DOI 10.1109/JRFID.2024.3406890, 2024,
              <https://doi.org/10.1109/JRFID.2024.3406890>.

Appendix A.  Acknowledgments

   The author thanks the DTN Working Group for discussion of this topic.

Author's Address

   N. Dheelep Sai Gupthaa
   India
   Email: dheelep.phd@gmail.com

Gupthaa                   Expires 30 April 2027                 [Page 5]