Bundle Protocol Security (BPSec)
Extracted elements (30)
A bundle can have multiple security blocks from different security sources added at different points in the DTN path. This reflects the store-carry-forward architecture where waypoints may add extension blocks and corresponding security services.
BPSec applies security at block-level granularity because different blocks within a bundle represent different types of information with different security needs. For example, a payload might be encrypted while a summary extension block is integrity-signed but unencrypted to allow waypoint inspection.
BPSec uses user-defined, parameterized security contexts rather than mandating a single cipher suite. This allows flexibility across deployments with different algorithm preferences (e.g., SHA-2 vs. SHA-3) and resource constraints without defining separate contexts for each configuration.
Security block processing order must be deterministic and identical across all nodes. This specification mandates a specific processing order (BCBs before BIBs when they share a security target) even at the cost of flexibility, to prevent ambiguity.
Hop-by-hop authentication is explicitly NOT a supported BPSec security service. The term 'hop-by-hop' is ambiguous in BP overlays since adjacent overlay nodes may not be physically adjacent, and incompatible security capabilities at adjacent nodes make enforcement infeasible.
A BCB or BIB MUST NOT be added to a bundle if the 'Bundle is a fragment' flag is set in the bundle processing control flags. Security operations are not applied to fragment bundles due to the complexity of payload-block fragmentation.
A security target MUST be represented as the block number of the target block, using the block number field defined in RFC 9171. This ensures unambiguous identification during security block processing.
All BPSec implementations MUST support at least the current mandatory security context(s) defined in IETF Standards Track RFCs. As of this writing, that is the context specified in RFC 9173.
Any security context used by a BCB MUST utilize a confidentiality cipher that provides authenticated encryption with associated data (AEAD). This ensures ciphertext integrity is always coupled with confidentiality.
BCBs MUST have the 'Block must be replicated in every fragment' flag set if one of its targets is the payload block. BCBs MUST NOT have the 'Block must be removed from bundle if it can't be processed' flag set, as removing a BCB without decrypting its targets would prevent later decryption.
CBOR values in the primary block MUST be canonicalized using Deterministically Encoded CBOR (RFC 8949). For non-primary blocks, only the block-type-specific data field MAY be provided to a cipher suite for encryption; other block fields MUST NOT be encrypted.
For a given security target, BIBs MUST be added before BCBs. This ordering MUST be preserved both at bundle creation and when waypoints add security blocks to existing bundles.
If a receiving node is the bundle destination, it MUST decrypt any BCBs remaining in the bundle. If a BCB cannot be decrypted (ciphertext authentication failure), the bundle MUST be discarded. Recovered plaintext MUST replace ciphertext in each security target's block-type-specific data field.
Security context specifications MUST define parameter Ids and their CBOR encoding, security result Ids and their CBOR encoding, and whether associated cipher suites generate ciphertext of a different size than the input plaintext.
Security operations in a bundle MUST be unique: the same security service MUST NOT be applied to the same security target more than once. A new security block MUST NOT be added if a preexisting security block of the same type already covers the same target.
When a BCB shares security targets with a BIB, the BIB MUST also be encrypted. If targets overlap partially, the BIB must be split and the portion covering BCB targets encrypted. A BIB MUST NOT be added for a target already covered by a BCB.
When BIBs and BCBs share a security target, BCBs MUST be evaluated first and BIBs second. A BIB MUST NOT be processed if its security target is also the security target of a BCB in the bundle.
The Abstract Security Block (ASB) is the common data structure shared by BIB and BCB. Its fields in order are: Security Targets (CBOR array of unsigned integers), Security Context Id (CBOR unsigned integer), Security Context Flags (CBOR unsigned integer bit field), Security Source (CBOR array EID), optional Security Context Parameters (CBOR array of Id/value 2-tuples), and Security Results (CBOR array of per-target result arrays).
The Block Confidentiality Block (BCB) encrypts security target block-type-specific data in-place so the target contains ciphertext after processing. BCBs MUST use an AEAD cipher and MUST NOT target another BCB or the primary block.
The Block Integrity Block (BIB) is a BP extension block that ensures plaintext integrity of its security targets. BIBs MAY be verified at any hop, MUST NOT target security blocks defined in this specification, and MUST NOT be used for integrity protection of BCB-generated ciphertext.
IANA is requested to add five security-related reason codes to the Bundle Status Report Reason Codes registry: 'Missing security operation', 'Unknown security operation', 'Unexpected security operation', 'Failed security operation', and 'Conflicting security operation'.
IANA is requested to assign block type codes for the Block Integrity Block (BIB) and Block Confidentiality Block (BCB) in the Bundle Block Types registry established by RFC 9171.
IANA is requested to create a new 'Security Context Identifiers' registry for BPSec security context IDs. Security context Id values are CBOR unsigned integers referenced in the Security Context Id field of the ASB.
BCB confidentiality protects against eavesdropping, but long-lived bundles (potentially persisting for years in DTN) increase exposure time and allow offline decryption attempts. Cipher suites must be selected to provide protection over the expected data lifetime.
Block removal attacks (removing a BCB or BIB without its target, or removing both) leave no in-band evidence. BPSec must be combined with out-of-band policy specifying required security operations on transmission and reception to detect such attacks.
BPSec cannot encrypt the primary block, leaving it vulnerable to topology attacks where an on-path attacker modifies routing fields. Mitigations such as BIBs on the primary block, encapsulation, or routing policy enforcement must be used but are outside BPSec scope.
BPSec defines three attacker classes: Unprivileged (no provisioned keys), Legitimate (has its own provisioned keys K_M), and Privileged (has keys of Alice and/or Bob). A privileged attacker constitutes full compromise; BPSec provides no mechanism to detect or remove such an attacker.
Replay and message injection attacks are mitigated by cipher suite capabilities in BCBs and by signing bundle primary block fields (timestamp, lifetime, Bundle Age block) with a BIB. Anti-replay mechanisms such as nonces and session identifiers MAY be included as security context parameters.
Security Context Flags is a CBOR unsigned integer interpreted as a bit field. Bit 0 (0x01) is the 'Security context parameters present' flag. Implementations MUST set reserved bits to 0 when writing and MUST ignore reserved bits when reading.
Security Results is a CBOR array of per-target result arrays, ordered identically to the Security Targets field. Each individual result is a CBOR 2-tuple of Result Id (CBOR unsigned integer) and Result Value (context-defined CBOR encoding). There MUST be exactly one target results entry per security target.