RFC 9172
Bundle Protocol Security (BPSec)
RFC 9172: Bundle Protocol Security (BPSec) ✨
okay bestie, let's get into it 🦋 this one is by E. Birrane, III and K. McKeever (both at JHU/APL 🎀), it's a Standards Track document, it's dated January 2022, and it's published in the ISSN 2070-1721 series. it doesn't obsolete or update anything, so it's a fresh start 🌸
Abstract
This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). 💜
Status of This Memo ✨
This is an Internet Standards Track document. 🎀
This document is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community 🫶 it's had public review and got approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 💅
info about the current status of this doc, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9172 🌈
Copyright Notice 💖
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. all rights reserved. 🔒
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. please actually read those, bestie, they explain your rights and restrictions 📜 code components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚠️
Table of Contents 🗺️
1. Introduction
1.1. Supported Security Services
1.2. Specification Scope
1.3. Related Documents
1.4. Terminology
2. Design Decisions
2.1. Block-Level Granularity
2.2. Multiple Security Sources
2.3. Mixed Security Policy
2.4. User-Defined Security Contexts
2.5. Deterministic Processing
3. Security Blocks
3.1. Block Definitions
3.2. Uniqueness
3.3. Target Multiplicity
3.4. Target Identification
3.5. Block Representation
3.6. Abstract Security Block
3.7. Block Integrity Block
3.8. Block Confidentiality Block
3.9. Block Interactions
3.10. Parameter and Result Identification
3.11. BPSec Block Examples
3.11.1. Example 1: Constructing a Bundle with Security
3.11.2. Example 2: Adding More Security at a New Node
4. Canonical Forms
5. Security Processing
5.1. Bundles Received from Other Nodes
5.1.1. Receiving BCBs
5.1.2. Receiving BIBs
5.2. Bundle Fragmentation and Reassembly
6. Key Management
7. Security Policy Considerations
7.1. Security Reason Codes
8. Security Considerations
8.1. Attacker Capabilities and Objectives
8.2. Attacker Behaviors and BPSec Mitigations
8.2.1. Eavesdropping Attacks
8.2.2. Modification Attacks
8.2.3. Topology Attacks
8.2.4. Message Injection
9. Security Context Considerations
9.1. Mandating Security Contexts
9.2. Identification and Configuration
9.3. Authorship
10. Defining Other Security Blocks
11. IANA Considerations
11.1. Bundle Block Types
11.2. Bundle Status Report Reason Codes
11.3. Security Context Identifiers
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🌷
1.1. Supported Security Services 🔐
okay so we're going to talk about the security features now! 💅
This document defines security features for the Bundle Protocol (BP) [RFC9171] and it's meant for Delay-Tolerant Networking (DTN) 🚀 it gives security services between a security source and a security acceptor. when the security source is the bundle source and the security acceptor is the bundle destination, you get end-to-end protection 🎀
the BP spec [RFC9171] describes DTN as "a network architecture providing communications in and/or through highly stressed environments," where "BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network" 🦋 a "stressed environment" is one with lots of challenges going on at once: intermittent connectivity, big and/or changing delays, asymmetric data rates, and high bit error rates 😭
BP is supposed to be deployed in an untrusted network, which brings the usual security headaches around confidentiality and integrity 🙈 but the stressed environment BP lives in is a whole different beast, so normal transport security might not be enough. for example, store-carry-forward might mean data has to be protected while it's sitting at rest, stopping unauthorized folks from eating up critical resources like storage space, and working without regular contact with a centralized security oracle (like a certificate authority) 💀
we need an end-to-end security service that works in every environment where BP works ✨
Okay, now the security services themselves! 💖
Integrity services make sure changes to target data inside a bundle can be discovered. those changes could come from processing errors, environmental conditions, or someone intentionally messing with it 🔥 in BPSec, integrity services apply to plaintext in the bundle 🌸
Confidentiality services make sure target data is unintelligible to nodes in DTN, except for authorized nodes that have some special info 🧚 generally this means turning plaintext into ciphertext and generating authentication information for that ciphertext 💜 confidentiality covers the contents of target data, but it doesn't hide the fact that confidentiality exists in the bundle 🫶
NOTE: Hop-by-hop authentication is NOT a supported security service in this specification, for two reasons:
- the term "hop-by-hop" is ambiguous in a BP overlay, since nodes that are adjacent in the overlay might not be adjacent in physical connectivity 😵 that's really hard or impossible to detect, so hop-by-hop authentication is hard or impossible to enforce 🙃
- hop-by-hop authentication can't be deployed in a network if adjacent nodes have incompatible security capabilities 🚫
1.2. Specification Scope 🗺️
This document defines the security services provided by BPSec. that includes the data spec for representing these services as BP extension blocks, plus the rules for adding, removing, and processing those blocks at various points while a bundle travels through a delay-tolerant network 🚂
BPSec only protects data traveling over the DTN, not the DTN itself 🛡️ and while BPSec can give security-at-rest in a store-carry-forward network, it doesn't cover threats that share computing resources with the DTN and/or BPSec software implementations 😬 those threats could be malicious software or compromised libraries trying to intercept data or grab cryptographic material. so it's on the BPSec implementer to make sure any cryptographic material, including shared secrets or private keys, is protected against access in both memory and storage devices 🔐
completely trusted networks are super rare 🥲 across untrusted networks, different conditions and operational needs call for security mechanisms of different strengths. mandating a single security context (a set of assumptions, algorithms, configurations, and policies used to implement security services) might be too much security for some networks and too little for others 🎭 default security contexts are defined in [RFC9173] to give basic security services for interoperability testing and for operational use on the terrestrial Internet 🌍 separate documents are expected to define different security contexts for different networks 📚
this spec doesn't address whether externally defined cryptographic methods are fit for use, or how secure their implementation is 🤷♀️
this spec doesn't cover implementing security policies and doesn't provide a security policy for BPSec. like cipher suites, security policies depend on the nature and capabilities of individual networks and their operational concepts 🧁 it does give policy considerations you can take into account when building one 💡
apart from the Bundle Protocol itself, this spec doesn't explain how to combine BPSec security blocks with other protocols, other BP extension blocks, or other best practices to get security in a particular network implementation 🙃
1.3. Related Documents 📚
this doc is best read alongside these other DTN docs, bestie 🫶
- "Delay-Tolerant Networking Architecture" [RFC4838] defines the architecture for DTN and points out certain security assumptions made by existing Internet protocols that aren't valid in DTN 🌐
- "Bundle Protocol Version 7" [RFC9171] defines the format and processing of bundles, the extension block format used to represent BPSec security blocks, and the canonical block structure used by this spec 🎀
- "Concise Binary Object Representation (CBOR)" [RFC8949] defines a data format with small code size, fairly small message size, and extensibility without version negotiation 🧩 the block-type-specific data for BPSec security blocks is encoded in this format 💜
- "Bundle Security Protocol Specification" [RFC6257] introduces the idea of using BP extension blocks for security services in DTN ✨ BPSec is a continuation and refinement of that doc 🦋
(this is part 1 of 10, so more is coming! stay tuned bestie 💅🌈)
1.4. Terminology 💖
okay bestie, the key words below are the only ones written in all caps, and they're what this whole spec runs on 🫶 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.
This section is the glossary 📚 Some of these terms are unique to BPSec, and the rest are needed just to follow the concepts in this spec. Let's go! ✨
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 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. 🔐
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 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, notated 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. This one is a big deal, so don't skip it 🙈
Security Service: a process that gives some protection to a security target. For example, this specification defines security services for plaintext integrity (bib-integrity) and authenticated plaintext confidentiality with additional authenticated data (bcb-confidentiality). 🛡️
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. 🌈
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. ⭐
2. Design Decisions 🎀
The application of security services in DTN is a complex endeavor that must consider physical properties of the network (such as connectivity and propagation times), policies at each node, application security requirements, and current and future threat environments. This section identifies those desirable properties that guide design decisions for this specification and that are necessary for understanding the format and behavior of the BPSec protocol. so many things to juggle, but we got this 💪
2.1. Block-Level Granularity 🧁
Security services within this specification must allow different blocks within a bundle to have different security services applied to them.
Blocks within a bundle represent different types of information. The primary block contains identification and routing information. The payload block carries application data. Extension blocks carry a variety of data that may augment or annotate the payload or that otherwise provide information necessary for the proper processing of a bundle along a path. Therefore, applying a single level and type of security across an entire bundle fails to recognize that blocks in a bundle represent different types of information with different security needs. not all blocks are the same, and that's the whole point 💖
For example, a payload block might be encrypted to protect its contents and an extension block containing summary information related to the payload might be integrity signed but unencrypted to provide waypoints access to payload-related data without providing access to the payload. 🦋
2.2. Multiple Security Sources 👑
A bundle can have multiple security blocks, and these blocks can have different security sources. BPSec implementations MUST NOT assume that all blocks in a bundle have the same security operations applied to them.
The Bundle Protocol allows extension blocks to be added to a bundle at any time during its existence in DTN. When a waypoint adds a new extension block to a bundle, that extension block MAY have security services applied to it by that waypoint. Similarly, a waypoint MAY add a security service to an existing block, consistent with its security policy.
When a waypoint adds a security service to the bundle, the waypoint is the security source for that service. The security block(s) that represent that service in the bundle may need to record this security source, as the bundle destination might need this information for processing.
For example, a bundle source may choose to apply an integrity service to its plaintext payload. Later a waypoint node, representing a gateway to another portion of the delay-tolerant network, may receive the bundle and choose to apply a confidentiality service. In this case, the integrity security source is the bundle source and the confidentiality security source is the waypoint node. 🌸
In cases where the security source and security acceptor are not the bundle source and bundle destination, respectively, it is possible that the bundle will reach the bundle destination prior to reaching a security acceptor. In cases where this may be a practical problem, it is recommended that solutions such as bundle encapsulation be used to ensure that a bundle be delivered to a security acceptor prior to being delivered to the bundle destination. Generally, if a bundle reaches a waypoint that has the appropriate configuration and policy to act as a security acceptor for a security service in the bundle, then the waypoint should act as that security acceptor. okay this is the kind of plot twist that needs a whole group chat 😭
2.3. Mixed Security Policy 🌷
The security policy enforced by nodes in the delay-tolerant network may differ.
Some waypoints will have security policies that require the waypoint to evaluate security services even if the waypoint is neither the bundle destination nor the final intended acceptor of the service. For example, a waypoint could choose to verify an integrity service even though the waypoint is not the bundle destination and the integrity service will be needed by other nodes along the bundle's path.
Some waypoints will determine, through policy, that they are the intended recipient of the security service and will terminate the security service in the bundle. For example, a gateway node could determine that, even though it is not the destination of the bundle, it should verify and remove a particular integrity service or attempt to decrypt a confidentiality service, before forwarding the bundle along its path. 🚪
Some waypoints could understand security blocks but refuse to process them unless they are the bundle destination. 🙅♀️
2.4. User-Defined Security Contexts 🧸
A security context is the set of assumptions, algorithms, configurations, and policies used to implement security services. Different contexts may specify different algorithms, different polices, or different configuration values used in the implementation of their security services. BPSec provides a mechanism to define security contexts. Users may select from registered security contexts and customize those contexts through security context parameters.
For example, some users might prefer a SHA2 hash function for integrity, whereas other users might prefer a SHA3 hash function. Providing either separate security contexts or a single, parameterized security context allows users flexibility in applying the desired cipher suite, policy, and configuration when populating a security block. choice is everything, bestie 🍑
2.5. Deterministic Processing 🔁
Whenever a node determines that it must process more than one security block in a received bundle (either because the policy at a waypoint states that it should process security blocks or because the node is the bundle destination), the order in which security blocks are processed must be deterministic. All nodes must impose this same deterministic processing order for all security blocks. This specification provides determinism in the application and evaluation of security services, even when doing so results in a loss of flexibility. predictable > flexible when it comes to security, no cap 🔒
3. Security Blocks 🧩
3.1. Block Definitions 💜
This specification defines two types of security block: the Block Integrity Block (BIB) and the Block Confidentiality Block (BCB).
- 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. 🔍
- 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.2. Uniqueness 🔒✨
Okay bestie, the golden rule of security blocks is no doubles!! 💅 Security operations in a bundle MUST be unique, and the same security service MUST NOT be applied to a security target more than once in a bundle. 😭 Since each security operation is represented by a security block, multiple security blocks of the same type cannot share the same security targets. And a new security block MUST NOT be added to a bundle if a preexisting security block of the same type is already defined for its security target. Periodt. 💀
This uniqueness rule is lowkey about clarity 🫶. It makes sure there is no confusion about the order in which security blocks get processed, and it keeps security policy simple when it needs to require certain security services to be present in a bundle.
Let's use the notation OP(service, target) to walk through some examples 🎀
- Signing the payload twice: The two operations
OP(bib-integrity, payload)andOP(bib-integrity, payload)are redundant and MUST NOT both be present in the same bundle at the same time. 🙈 - Signing different blocks: The two operations
OP(bib-integrity, payload)andOP(bib-integrity, extension_block_1)are not redundant and both may be present in the same bundle at the same time. Similarly, the two operationsOP(bib-integrity, extension_block_1)andOP(bib-integrity, extension_block_2)are also not redundant and may both be present in the bundle at the same time. 🧚 - Different services on same block: The two operations
OP(bib-integrity, payload)andOP(bcb-confidentiality, payload)are not inherently redundant and may both be present in the bundle at the same time, pursuant to other processing rules in this specification. 🌈 - Different services from different block types: The notation
OP(service, target)refers specifically to a security block, because the security block is the embodiment of a security service applied to a security target in a bundle. Were some Other Security Block (OSB) to be defined providing an integrity service, then the operationsOP(bib-integrity, target)andOP(osb-integrity, target)MAY both be present in the same bundle if so allowed by the definition of the OSB, as discussed in Section 10. 🦋
NOTES:
- A security block may be removed from a bundle as part of security processing at a waypoint node, with a new security block being added to the bundle by that node. In this case, conflicting security blocks never coexist in the bundle at the same time, so the uniqueness requirement is not violated. 🍓
- A ciphertext integrity-protection mechanism (such as associated authenticated data) calculated by a cipher suite and transported in a BCB is considered part of the confidentiality service. Therefore, it is unique from the plaintext integrity service provided by a BIB. 💜
- The security blocks defined in this specification (BIB and BCB) are designed with the intention that the BPA adding these blocks is the authoritative source of the security service. If a BPA adds a BIB on a security target, then the BIB is expected to be the authoritative source of integrity for that security target. If a BPA adds a BCB to a security target, then the BCB is expected to be the authoritative source of confidentiality for that security target. More complex scenarios, such as having multiple nodes in a network sign the same security target, can be accommodated using the definition of custom security contexts (see Section 9) and/or the definition of OSBs (see Section 10). 👑
3.3. Target Multiplicity 🦋
Okay so a single security block MAY represent multiple security operations, which is a super cute way to cut down on how many security blocks are floating around in a bundle 🎀. Fewer blocks means less redundant info, and that's giving efficiency ✨.
A set of security operations can be represented by a single security block when all of the following conditions are true:
- The security operations apply the same security service. For example, they are all integrity operations or all confidentiality operations.
- The security context parameters for the security operations are identical.
- The security source for the security operations is the same, meaning the set of operations are being added by the same node.
- No security operations have the same security target, as that would violate the need for security operations to be unique.
- None of the security operations conflict with security operations already present in the bundle.
When you bundle multiple security operations into one security block, the info that's shared across all of them gets written once 💖. The info that's different (like the security targets, e.g.) gets written out individually.
If a node processes any security operation in a security block, it is RECOMMENDED that it process all security operations in that security block 🫶. This lets security sources say that the whole set of security operations is expected to be handled by the same security acceptor. Whether a node actually is a security acceptor, though, is up to that node's own policy 💅. If a receiving node decides that it is the security acceptor for only a subset of the security operations in a security block, the node may choose to process just that subset.
3.4. Target Identification 🎯
A security target is a block in the bundle that a security service applies to. This target must be uniquely and unambiguously identifiable when processing a security block 👀. Good news: the extension block header from [RFC9171] already has a "block number" field that's perfect for this 🧚. So a security target in a security block MUST be represented as the block number of the target block. Iconic. ✨
3.5. Block Representation 📦
Every security block uses the Canonical Bundle Block Format as defined in [RFC9171]. So each security block is made up of the following elements:
- block type code
- block number
- block processing control flags
- cyclic redundancy check (CRC) type
- block-type-specific data
- CRC field (if present)
All the security-specific info for a security block lives in the block-type-specific data field 🌸.
3.6. Abstract Security Block ✨
okay so BIB and BCB blocks have the same security-specific bits inside them, which is lowkey iconic because it means we only have to explain them once 💅 this section makes an Abstract Security Block (ASB) to cover that shared stuff. ngl, an ASB never actually shows up in a bundle. it's just a way to talk about what BIB and BCB have in common 🦋
The fields of the ASB SHALL be as follows, listed in the order in which they must appear. The encoding of these fields MUST be in accordance with the canonical forms provided in Section 4.
Security Targets: This field identifies the block(s) targeted by the security operation(s) represented by this security block. Each target block is represented by its unique block number. This field SHALL be represented by a Concise Binary Object Representation (CBOR) array of data items. Each target within this CBOR array SHALL be represented by a CBOR unsigned integer. This array MUST have at least one entry and each entry MUST represent the block number of a block that exists in the bundle. There MUST NOT be duplicate entries in this array. The order of elements in this list has no semantic meaning outside of the context of this block. Within the block, the ordering of targets must match the ordering of results associated with these targets.
Security Context Id: This field identifies the security context used to implement the security service represented by this block and applied to each security target. This field SHALL be represented by a CBOR unsigned integer. The values for this Id should come from the registry defined in Section 11.3.
Security Context Flags: This field identifies which optional fields are present in the security block. This field SHALL be represented as a CBOR unsigned integer whose contents shall be interpreted as a bit field. Each bit in this bit field indicates the presence (bit set to 1) or absence (bit set to 0) of optional data in the security block. The association of bits to security block data is defined as follows.
Bit 0 (the least-significant bit, 0x01): "Security context
parameters present" flag.
Bit >0 ReservedImplementations MUST set reserved bits to 0 when writing this field and MUST ignore the values of reserved bits when reading this field. For unreserved bits, a value of 1 indicates that the associated security block field MUST be included in the security block. A value of 0 indicates that the associated security block field MUST NOT be in the security block.
Security Source: This field identifies the BPA that inserted the security block in the bundle. Also, any node ID of the node of which the BPA is a component. This field SHALL be represented by a CBOR array in accordance with the rules in [RFC9171] for representing endpoint IDs (EIDs).
Security Context Parameters (Optional): This field captures one or more security context parameters that should be used when processing the security service described by this security block. This field SHALL be represented by a CBOR array. Each entry in this array is a single security context parameter. A single parameter SHALL also be represented as a CBOR array comprising a 2-tuple of the Id and value of the parameter, as follows.
- Parameter Id: This field identifies which parameter is being specified. This field SHALL be represented as a CBOR unsigned integer. Parameter Ids are selected as described in Section 3.10.
- Parameter Value: This field captures the value associated with this parameter. This field SHALL be represented by the applicable CBOR representation of the parameter, in accordance with Section 3.10.
The logical layout of the parameters array is illustrated in Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Security Context ParametersSecurity Results: This field captures the results of applying a security service to the security targets of the security block. This field SHALL be represented as a CBOR array of target results. Each entry in this array represents the set of security results for a specific security target. The target results MUST be ordered identically to the Security Targets field of the security block. This means that the first set of target results in this array corresponds to the first entry in the Security Targets field of the security block, and so on. There MUST be one entry in this array for each entry in the Security Targets field of the security block.
The set of security results for a target is also represented as a CBOR array of individual results. An individual result is represented as a CBOR array comprising a 2-tuple of a result Id and a result value, defined as follows.
- Result Id: This field identifies which security result is being specified. Some security results capture the primary output of a cipher suite. Other security results contain additional annotative information from cipher suite processing. This field SHALL be represented as a CBOR unsigned integer. Security result Ids will be as specified in Section 3.10.
- Result Value: This field captures the value associated with the result. This field SHALL be represented by the applicable CBOR representation of the result value, in accordance with Section 3.10.
The logical layout of the security results array is illustrated in Figure 2. In this figure, there are N security targets for this security block. The first security target contains M results and the Nth security target contains K results.
+--------------------------+ +---------------------------+
| Target 1 | | Target N |
+----------+----+----------+ +---------------------------+
| Result 1 | | Result M | ... | Result 1 | | Result K |
+----+-----+ .. +----+-----+ +---+------+ .. +----+------+
| Id |Value| | Id |Value| | Id |Value| | Id | Value|
+----+-----+ +----+-----+ +----+-----+ +----+------+
Figure 2: Security Results3.7. Block Integrity Block 🔐
okay the Block Integrity Block (BIB) is a BP extension block, and it has some main character rules 👑
- The block type code value is as specified in Section 11.1.
- The block-type-specific data field follows the structure of the ASB.
- A security target listed in the Security Targets field MUST NOT reference a security block defined in this specification (e.g., a BIB or a BCB).
- The security context MUST utilize an authentication mechanism or an error detection mechanism.
Notes, bestie 🫶
- Designers SHOULD carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
- Since OP(bib-integrity, target) is allowed only once in a bundle per target, it is RECOMMENDED that users wishing to support multiple integrity-protection mechanisms for the same target define a multi-result security context. Such a context could generate multiple security results for the same security target using different integrity-protection mechanisms or different configurations for the same integrity-protection mechanism.
- A BIB is used to verify the plaintext integrity of its security target. However, a single BIB MAY include security results for blocks other than its security target when doing so establishes a needed relationship between the BIB security target and other blocks in the bundle (such as the primary block).
- Security information MAY be checked at any hop on the way to the bundle destination that has access to the required keying information, in accordance with Section 3.9.
3.8. Block Confidentiality Block 🔒
the Block Confidentiality Block (BCB) is also a BP extension block, and it's giving secret-keeper energy 🤫
- The block type code value is as specified in Section 11.1.
- The block processing control flags value can be set to whatever values are required by local policy with the following exceptions:
- BCBs MUST have the "Block must be replicated in every fragment" flag set if one of the targets is the payload block. Having that BCB in each fragment indicates to a receiving node that the payload portion of each fragment represents ciphertext.
- BCBs MUST NOT have the "Block must be removed from bundle if it can't be processed" flag set. Removing a BCB from a bundle without decrypting its security targets removes information from the bundle necessary for their later decryption.
- The block-type-specific data fields follow the structure of the ASB.
- A security target listed in the Security Targets field can reference the payload block, a non-security extension block, or a BIB. A BCB MUST NOT include another BCB as a security target. A BCB MUST NOT target the primary block. A BCB MUST NOT target a BIB unless it shares a security target with that BIB.
- Any security context used by a BCB MUST utilize a confidentiality cipher that provides authenticated encryption with associated data (AEAD).
- Additional information created by a cipher suite (such as an authentication tag) can be placed either in a security result field or in the generated ciphertext. The determination of where to place this information is a function of the cipher suite and security context used.
The BCB modifies the contents of its security target(s). When a BCB is applied, the security target body data are encrypted "in-place". Following encryption, the security target block-type-specific data field contains ciphertext, not plaintext.
Notes, bestie 💜
- It is RECOMMENDED that designers carefully consider the effect of setting flags that delete the bundle in the event that this block cannot be processed.
- The BCB block processing control flags can be set independently from the processing control flags of the security target(s). The setting of such flags should be an implementation/policy decision for the encrypting node.
3.9. Block Interactions
okay so the security block types in this spec are designed to be as independent as possible 💅 but there are some moments where blocks might share a security target, and that sharing creates processing dependencies 👀
if a BCB and a BIB share a security target, things get messy 🙈 a waypoint wouldn't be able to validate the BIB, because the shared target has already been encrypted by the BCB. so to avoid that mess, these processing rules MUST be followed:
- When adding a BCB to a bundle, if some (or all) of the security targets of the BCB match all of the security targets of an existing BIB, then the existing BIB MUST also be encrypted. You can do this by adding a new BCB that targets the existing BIB, or by adding the BIB to the list of security targets for the BCB. Which way you pick is a matter of security policy 🎀
- When adding a BCB to a bundle, if some (or all) of the security targets of the BCB match some (but not all) of the security targets of a BIB, then that BIB MUST be altered like this. Any security results in the BIB associated with the BCB security targets MUST be removed from the BIB and placed in a new BIB. This newly created BIB MUST then be encrypted. You can encrypt the new BIB by adding a new BCB that targets it, or by adding it to the list of security targets for the BCB. Again, the choice is a matter of security policy ✨
- A BIB MUST NOT be added for a security target that is already the security target of a BCB, because that would cause ambiguity in block processing order 😭
- A BIB integrity value MUST NOT be checked if the BIB is the security target of an existing BCB. In this case, the BIB data is encrypted 🔒
- A BIB integrity value MUST NOT be checked if the security target associated with that value is also the security target of a BCB. In that situation, the security target data contains ciphertext because it has been encrypted 🧚
- As mentioned in Section 3.7, a BIB MUST NOT have a BCB as its security target. no exceptions bestie 💜
These restrictions impose a necessary ordering when applying security operations within a bundle. Specifically, for a given security target, BIBs MUST be added before BCBs. This ordering MUST be preserved when the current BPA is adding all of the security blocks for the bundle, and also when the BPA is a waypoint adding new security blocks to a bundle that already has security blocks 🍓
Now, if a security source wants to calculate a plaintext integrity-protection mechanism AND encrypt a security target, it MUST use a BCB whose security context generates an integrity-protection mechanism as one or more additional security results. Do NOT add a BIB and then a BCB for the same security target at the security source. that's the move 🦋
3.10. Parameter and Result Identification
every security context MUST define its own context parameters and results 📋 each defined parameter and result is represented as a tuple of an identifier and a value. identifiers are always a CBOR unsigned integer, and the CBOR encoding of values is as defined by the security context specification 🌸
identifiers MUST be unique for a given security context, but they do NOT need to be unique across all security contexts. so you can reuse numbers between contexts, no drama 💅
an example of a security context can be found in [RFC9173] ✨
3.11. BPSec Block Examples
this section has two examples of BPSec blocks applied to bundles 🎀 in the first one, a single node adds several security operations to a bundle. in the second, a waypoint node receives the bundle from the first example and adds more security operations. in both examples, the first column shows the blocks in the bundle, and the second column shows the block number, using B1...Bn just for illustration 💖
3.11.1. Example 1: Constructing a Bundle with Security
so in this example, the bundle has four non-security blocks: the primary block (B1), two extension blocks (B4, B5), and a payload block (B6). the bundle source wants an integrity signature over the plaintext of the primary block, the second extension block, and the payload 🔐 it also wants confidentiality for the first extension block 🫶 the result is shown in Figure 3, and the security actions are described below.
Block in Bundle ID
+==========================================+====+
| Primary Block | B1 |
+------------------------------------------+----+
| BIB | B2 |
| OP(bib-integrity, targets = B1, B5, B6)| |
+------------------------------------------+----+
| BCB | B3 |
| OP(bcb-confidentiality, target = B4) | |
+------------------------------------------+----+
| Extension Block (encrypted) | B4 |
+------------------------------------------+----+
| Extension Block | B5 |
+------------------------------------------+----+
| Payload Block | B6 |
+------------------------------------------+----+Figure 3: Security at Bundle Creation
these security actions were applied when the bundle was created 🌈
- An integrity signature was applied to the canonical form of the primary block (B1), the canonical form of the block-type-specific data field of the second extension block (B5), and the canonical form of the payload block (B6). This is done with a single BIB (B2) that has multiple targets. a single BIB is used here because all three targets share a security source, security context, and security context parameters. if that hadn't been the case, multiple BIBs could have been added instead 💜
- Confidentiality was applied to the first extension block (B4). This is done with a BCB (B3). Once applied, the block-type-specific data field of extension block B4 is encrypted. The BCB MUST hold an authentication tag for the ciphertext, either in the ciphertext that now fills the first extension block or as a security result in the BCB itself. Which one depends on the security context used to form the BCB 🧚 A plaintext integrity signature may also exist as a security result in the BCB, if the selected confidentiality security context provides one ✨
3.11.2. Example 2: Adding More Security at a New Node
okay now imagine the bundle from Figure 3 gets received by a waypoint node that wants to encrypt the second extension block and the payload 👀 the waypoint's security policy is to let the existing BIBs for these blocks persist, since they may be required by the security policy at the bundle destination 🦋
the result is shown in Figure 4, and the security actions are described below. quick note: the block IDs here are ordered only for this example, and they are NOT meant to impose an ordering for block creation. The ordering of blocks added to a bundle MUST always comply with [RFC9171] 🍓
Block in Bundle ID
+==========================================+====+
| Primary Block | B1 |
+------------------------------------------+----+
| BIB | B2 |
| OP(bib-integrity, target = B1) | |
+------------------------------------------+----+
| BIB (encrypted) | B7 |
| OP(bib-integrity, targets = B5, B6) | |
+------------------------------------------+----+
| BCB | B8 |
|OP(bcb-confidentiality,targets = B5,B6,B7)| |
+------------------------------------------+----+
| BCB | B3 |
| OP(bcb-confidentiality, target = B4) | |
+------------------------------------------+----+
| Extension Block (encrypted) | B4 |
+------------------------------------------+----+
| Extension Block (encrypted) | B5 |
+------------------------------------------+----+
| Payload Block (encrypted) | B6 |
+------------------------------------------+----+Figure 4: Security at Bundle Forwarding
these security actions were applied to the bundle before the waypoint forwarded it 🚀
- The waypoint wants to encrypt the block-type-specific data fields of blocks B5 and B6, so it MUST also encrypt the block-type-specific data fields of the BIBs that provide plaintext integrity over those blocks. But BIB B2 couldn't be encrypted in its entirety, because it also held a signature for the primary block (B1). So a new BIB (B7) gets created, and the security results associated with B5 and B6 are moved out of BIB B2 and into BIB B7 💖
- Now there's no more confusion about which plaintext integrity signatures must be encrypted 🙌 so a BCB is added to the bundle, with the second extension block (B5), the payload (B6), and the newly created BIB holding their plaintext integrity signatures (B7) as its security targets. A single new BCB is used here because all three targets share a security source, security context, and security context parameters. If that hadn't been the case, multiple BCBs could have been added instead 💅
4. Canonical Forms 🧩✨
Okay so security services need EVERYTHING to be consistent and deterministic about how info gets handed to cipher suites at security sources, verifiers, and acceptors 💅. Like, integrity services need the same target info (same bits, same order, no cap) to be fed into the cipher suite when you make a signature AND when you check it. That's where canonicalization algorithms come in. They transcode the contents of a security target into a canonical form 🦋
Canonical forms are what get used to generate input to a security context for security processing at a BP node. The vibe is: if the values of a security target stay the same, then the canonical form stays the same too, even if those values are encoded differently for wire transmission 🌸
BPSec works on data fields inside bundle blocks (e.g., the block-type-specific data field) 🎀 In their canonical form, these fields MUST include their own CBOR encoding and MUST NOT include any other encapsulating CBOR encoding. So for example, the canonical form of the block-type-specific data field is a CBOR byte string sitting inside the CBOR array that holds the fields of the extension block. The whole CBOR byte string counts as the canonical block-type-specific data field, and the CBOR array framing is NOT part of the field 🙈
The canonical form of the primary block follows [RFC9171], with one extra constraint:
- CBOR values from the primary block MUST be canonicalized using the rules for Deterministically Encoded CBOR, as specified in [RFC8949].
All non-primary blocks share the same block structure, so they get canonicalized as specified in [RFC9171] with these constraints 🍓
- CBOR values from the non-primary block MUST be canonicalized using the rules for Deterministically Encoded CBOR, as specified in [RFC8949].
- Only the block-type-specific data field may be provided to a cipher suite for encryption as part of a confidentiality security service. Other fields within a non-primary block MUST NOT be encrypted or decrypted and MUST NOT be included in the canonical form used by the cipher suite for encryption and decryption. An integrity-protection mechanism MAY be applied to these other fields as supported by the security context. For example, these fields might be treated as associated authenticated data 🔥
- Reserved and unassigned flags in the block processing control flags field MUST be set to 0 in a canonical form, because it's not known whether those flags will change in transit 🌈
Security contexts MAY define their own canonicalization algorithms and require the use of those over the ones in this specification. If canonicalization algorithms ever conflict, the ones defined in a security context take precedence over this specification when building canonical forms for that security context 👑
5. Security Processing 🔐
This section is all about the security side of bundle processing 💖
5.1. Bundles Received from Other Nodes 📦
Security blocks must be processed in a specific order when a BP node receives them. The order goes like this:
- When BIBs and BCBs share a security target, BCBs MUST be evaluated first and BIBs second.
5.1.1. Receiving BCBs 🔓
If a received bundle contains a BCB, the receiving node MUST figure out whether it's the security acceptor for any of the security operations in that BCB. If it is, the node MUST process those operations and remove any operation-specific info from the BCB before delivering data to an application at the node or forwarding the bundle. If processing a security operation fails, the target SHALL be processed according to the security policy. A bundle status report about the failure MAY be generated. Once all the security operations for a BCB have been removed, the BCB MUST be removed from the bundle 🫶
If the receiving node is the destination of the bundle, the node MUST decrypt any BCBs still left in the bundle. If the receiving node is NOT the destination, the node MUST process the BCB only if it's been told to do so as a matter of security policy 💅
If a node's security policy says it should have applied confidentiality to a specific security target, but no such BCB is in the bundle, then the node MUST process that security target according to the security policy. It is RECOMMENDED that the node remove the security target from the bundle, because the confidentiality (and possibly the integrity) of that target can't be guaranteed. If the removed security target is the payload block, the bundle MUST be discarded 😭
If an encrypted payload block can't be decrypted (i.e., the ciphertext can't be authenticated), then the bundle MUST be discarded and processed no further. If an encrypted security target other than the payload block can't be decrypted, then that target and all security blocks associated with it MUST be discarded and processed no further. In both cases, requested status reports (see [RFC9171]) MAY be generated to reflect the bundle or block deletion 💀
When a BCB is decrypted, the recovered plaintext for each security target MUST replace the ciphertext in each target's block-type-specific data field. If the plaintext is a different size than the ciphertext, the framing of that CBOR byte string must be updated so the field stays a valid CBOR byte string. The decrypting security context already knows the length of the recovered plaintext ✨
If a BCB contains multiple security operations, each operation the node processes MUST be treated as if it were represented by a single BCB with a single security operation, for the purposes of report generation and policy processing 🧚
5.1.2. Receiving BIBs ✍️
If a received bundle contains a BIB, the receiving node MUST figure out whether it's the security acceptor for any of the security operations in that BIB. If it is, the node MUST process those operations and remove any operation-specific info from the BIB before delivering data to an application at the node or forwarding the bundle. If processing a security operation fails, the target SHALL be processed according to the security policy. A bundle status report about the failure MAY be generated. Once all the security operations for a BIB have been removed, the BIB MUST be removed from the bundle 🌸
A BIB MUST NOT be processed if its security target is also the security target of a BCB in the bundle. Because of the order of operations this spec mandates, if a BIB and a BCB share a security target, that target must have been encrypted AFTER it was integrity signed. So the BIB can't be verified until the target has been decrypted by processing the BCB 🙈
If a node's security policy says it should have applied integrity to a specific security target, but no such BIB is in the bundle, then the node MUST process that target according to the security policy. It is RECOMMENDED that the node remove the security target from the bundle if it's not the payload or primary block. If it IS the payload or primary block, the bundle MAY be discarded. This can happen at any node that's able to verify an integrity signature, not just the bundle destination 🦋
If a receiving node isn't the security acceptor of a security operation in a BIB, it MAY still try to verify that operation anyway, to avoid forwarding corrupt data. If verification fails, the node SHALL process the security target according to local security policy. If a payload integrity check fails at a waypoint, it is RECOMMENDED that it be handled the same way as a payload integrity check failure at the bundle destination. If the check passes, the node MUST NOT remove the security operation from the BIB before forwarding 🔥
If a BIB contains multiple security operations, each operation the node processes MUST be treated as if it were represented by a single BIB with a single security operation, for the purposes of report generation and policy processing 👑
5.2. Bundle Fragmentation and Reassembly 🧃
If a node needs to fragment a bundle payload and security services have been applied to that bundle, the fragmentation rules in [RFC9171] MUST be followed. As defined there (and summarized here for completeness), only the payload block can be fragmented. Security blocks, like ALL extension blocks, can never be fragmented 🌈
Fragmenting payload blocks is complicated, especially when you might have to fragment payload-block fragments again. So integrity and confidentiality operations are NOT to be applied to a bundle that represents a fragment. Specifically, 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 field 🎀
Security processing alongside payload-block fragmentation may be handled by other mechanisms outside the BPSec protocol, or by applying BPSec blocks together with an encapsulation mechanism. A node should apply any confidentiality protection BEFORE it does any fragmentation 💜
6. Key Management 🗝️
There are SO many ways to establish, communicate, and manage key info in DTN 🌍 Some DTN deployments might follow established key management protocols, while others might need brand-new, novel approaches. BPSec assumes key management is handled as a separate part of network management. This specification neither defines nor requires any specific key management strategy 🫶
7. Security Policy Considerations 🎀
Okay bestie, implementing BPSec means making a bunch of policy decisions, and they must be considered 💅 This section covers the key policies that shape how bundles get generated, forwarded, and received when they're secured with this spec. Fair warning: there's no one-size-fits-all policy set for every secure DTN deployment 🌸
- Disallowed combos 🙈: If a bundle shows up with combinations of security operations that this specification doesn't allow, the BPA must figure out what to do with it. It may discard the bundle, it may discard the block the security operation affects, or it may favor one security operation over another.
- Who applies what 🧚: BPAs in the network need to know which security operations they should apply to bundles. That call can be based on the bundle's source, its destination, or some other info about the bundle.
- Already secured, thanks 💖: If a waypoint is configured to add a security operation, but the bundle it receives already has that operation applied, the receiver must know what to do. It can discard the bundle, discard the security target and its associated BPSec blocks, replace the security operation, or take some other action.
- Default to security 🔥: It is RECOMMENDED that security operations get applied to every block in a bundle, and that a BPA's default behavior is to use the security services defined in this specification. Designers should only skip security operations when they have a real justification, like when doing so would cause downstream errors while processing blocks whose contents have to be inspected or changed at one or more hops along the path.
- Size matters 📏: BCB security contexts can change the size of extension blocks and the payload block. Security policy SHOULD consider how a change in block size could negatively affect bundle processing, like calculating storage needs and scheduling transmission times.
- No BIB after BCB 🚫: Adding a BIB to a security target that's already been encrypted by a BCB is not allowed. If that situation is likely to come up, there are (at least) three policies that could handle it:
- At encryption time, pick a security context that computes a plaintext integrity-protection mechanism, and include it as a security context result field.
- Replicate the encrypted block as a new block with a new block number, and give that new block integrity protection.
- Apply an encapsulation scheme to the security target (or the entire bundle). The encapsulating structure is no longer the security target of a BCB, so it can be the security target of a BIB.
- Ciphertext size 👑: Security policy SHOULD address whether cipher suites whose ciphertext is larger than the initial plaintext are permitted, and if so, for which types of blocks. Changing a block's size can cause processing difficulties for networks that calculate block offsets into bundles, or that predict transmission times or storage availability based on bundle size. In other cases, changing the size of a payload during encryption has no significant impact ✨
7.1. Security Reason Codes
BPAs must process blocks and bundles according to both BP policy and BPSec policy 💅 The decision to receive, forward, deliver, or delete a bundle can be communicated to the bundle's report-to address as a status report, which helps track the bundle's progress through the network. That status report can also come with a "reason code" explaining why the action was taken 🦋
This section describes a set of reason codes tied to a bundle's security processing. Security-related status reports could weaken a network's security if unintended recipients intercept them 😭 BPSec policy SHOULD specify when it's appropriate to send security reason codes. Some examples of appropriate conditions include:
- When the report-to address has been verified as unchanged from the bundle source. This can happen by placing an appropriate BIB on the bundle primary block.
- When the block containing a status report with a security reason code is encrypted by a BCB.
- When a status report containing a security reason code is only sent for security issues involving bundles and/or blocks associated with non-operational user data or test data.
- When a status report containing a security reason code is only sent for security issues associated with non-operational security contexts, or security contexts using non-operational configurations, such as test keys.
Security reason codes get assigned according to Section 11.2, and here's what each one means 🌈
Missing security operation 🥺: A bundle was missing one or more required security operations. This reason code is typically used by a security verifier or security acceptor.
Unknown security operation 🤔: One or more security operations in a bundle can't be understood by the security verifier or security acceptor for that operation. For example, this code may be used if a security block references an unknown security context identifier or security context parameter. This reason code should not be used for security operations where the node isn't a security verifier or security acceptor. There's no requirement that every node in a network understand all security contexts, security context parameters, and security services for every bundle in that network.
Unexpected security operation 👀: A receiving node is neither a security verifier nor a security acceptor for at least one security operation in a bundle. This reason code should not be seen as an error condition, since not every node is a security verifier or security acceptor for every security operation in every bundle. In certain networks, though, this code can help identify misconfigurations of security policy 🧐
Failed security operation 💀: One or more security operations in a bundle failed to process as expected, for reasons other than misconfiguration. This may happen when a security-source is unable to add a security block to a bundle. It may also happen if the target of a security operation fails to verify using the defined security context at a security verifier. And it may happen if a security operation fails to be processed without error at a security acceptor.
Conflicting security operation ⚡: Two or more security operations in a bundle don't conform to the BPSec specification, and security processing couldn't proceed because of a BPSec protocol violation.
8. Security Considerations 🛡️
Bundles can travel through all sorts of environments and devices, and each one comes with its own unique security risks and requirements for implementing security within BPSec 🌍 That's why it's so important to lay out the key threat models and describe what BPSec is responsible for when it comes to protecting the confidentiality and integrity of data against those threats 🫶 This section digs into the security threats BPSec will face and explains how its security mechanisms work to mitigate them.
The threat model here is assumed to have the same capabilities as the Internet Threat Model described in [RFC3552]. The BPSec threat model is scoped to threats specific to BPSec running in DTN environments, so it focuses on on-path attackers (OPAs). In that setup, the delay-tolerant network (or significant portions of it) is assumed to be completely under an attacker's control 😈
8.1. Attacker Capabilities and Objectives
BPSec was designed to protect against OPA threats that might access a bundle while it's in transit from its source, Alice, to its destination, Bob 🎀 An OPA node, Olive, is a noncooperative node on the delay-tolerant network between Alice and Bob. Olive can receive, examine, modify, forward, and generate bundles at will, all to compromise the confidentiality or integrity of data in the delay-tolerant network 👑 There are three classes of OPA nodes, sorted by how much cryptographic material they can access:
Unprivileged Node: Olive hasn't been provisioned within the secure environment and only has access to cryptographic material that's been publicly shared.
Legitimate Node: Olive is within the secure environment, so Olive has access to cryptographic material provisioned to Olive (i.e., K_M) as well as material that's been publicly shared.
Privileged Node: Olive is a privileged node within the secure environment, so Olive has access to cryptographic material provisioned to Olive, Alice, and/or Bob (i.e., K_M, K_A, and/or K_B) as well as material that's been publicly shared.
If Olive is operating as a privileged node, that's basically a full compromise 😭 BPSec doesn't provide mechanisms to detect or remove Olive from the delay-tolerant network or the BPSec secure environment. It's up to the BPSec implementer or the underlying cryptographic mechanisms to provide appropriate capabilities if they're needed.
It's also worth noting that if an implementation of BPSec uses a single set of shared cryptographic material for all nodes, a legitimate node is equivalent to a privileged node, because K_M == K_A == K_B. For this reason, sharing cryptographic material in this way is not recommended 🙅♀️
A special case of the legitimate node is when Olive is either Alice or Bob (i.e., K_M == K_A or K_M == K_B). In that case, Olive can impersonate traffic as Alice or Bob, respectively, which means traffic to and from that node can be decrypted and encrypted, respectively. Olive could also sign messages as originating from one of the endpoints 🦋
8.2. Attacker Behaviors and BPSec Mitigations
8.2.1. Eavesdropping Attacks 🕵️♀️
okay so, Olive gets her hands on a bundle and can totally peek inside, right? 👀 She can try to recover protected data or keying material from any of the blocks in there. The thing BPSec throws at this problem is the BCB, which encrypts whatever its security target contains so the data stays confidential. But bestie, we have to assume Olive can attempt offline recovery of that encrypted data, so the crypto you pick to protect things needs to be strong enough to hold up. No cap, weak crypto is a whole vibe-killer 💀
When you're figuring out how risky eavesdropping is, the lifetime of bundles on DTN is a huge deal 🌸 Depending on the network, bundles can hang around for days or even years! Long-lived bundles mean the data is floating around for longer, so there are more chances for Olive to snag them 🎣 It also means the info inside stays relevant and sensitive for long enough that, once she has a copy, she has plenty of time to crack the encryption. Yikes 😭 So if a bundle sticks around for years and the cipher suite on the BCB isn't giving enough protection, Olive might recover the protected data either before the bundle reaches its intended destination, or before the info stops being sensitive. Iconic for her, not for us 🙈
NOTE: Olive is not limited by the bundle lifetime and may retain a given bundle indefinitely. 💅
NOTE: Irrespective of whether BPSec is used, traffic analysis will be possible. 👀
8.2.2. Modification Attacks 🛠️
okay, so as a node in the delay-tolerant network between Alice and Bob, Olive can also modify the bundle she received 😤 That includes non-BPSec stuff like the primary block, payload blocks, or the block processing control flags defined in [RFC9171]. She can change data inside blocks, replace blocks, add blocks, or remove blocks. Rude! But the BIB and BCB both bring integrity protection to detect or prevent these manipulation attempts by Olive ✨
The BIB gives that protection to another block, which is its security target. The crypto used to generate the BIB SHOULD be strong against collision attacks, and Olive SHOULD NOT have access to the key material the originating node used to make the BIB (like K_A) 🔑 If both of those are true, Olive can't modify the security target or the BIB, so she can't trick Bob into validating the security target as coming from Alice. Slay 💖
Here's the tricky part 🥺 BPSec works by putting blocks into a bundle, so there's no in-band way to detect or fix certain cases where Olive removes blocks. If Olive removes a BCB but keeps the security target, that target stays encrypted, and there might not be enough info left to decrypt it at the destination 😬 If Olive removes both a BCB (or BIB) and its security target, there's zero evidence of the security operation left in the bundle. Same deal if she removes the BIB but leaves the security target: no evidence left either. Ghosted, fr fr 👻 So in each of these cases, BPSec has to be paired with policy configuration at the endpoints that describes the security operations which MUST be applied on transmission and which are expected to be present on receipt. This, or other similar out-of-band info, is REQUIRED to correct for removal of security info in the bundle. Policy is literally the main character here 🎀
A limitation of the BIB may exist within the implementation of BIB validation at the destination node. 💀
Like, if Olive is a legit node in the DTN, the BIB Alice made with K_A can be swapped for a brand-new BIB generated with K_M and forwarded to Bob 😭 If Bob only checks that the BIB came from a legitimate user, Bob will happily acknowledge the message as coming from Olive instead of Alice. Lowkey awkward 🙃 Validating a BIB only tells you it was generated by a holder of the relevant key. It doesn't guarantee the bundle or block was created by that same entity. To get verifiable integrity checks, the BCB SHOULD require an encryption scheme that is Indistinguishable under adaptive Chosen Ciphertext Attack (IND-CCA2) secure 🔐 That kind of scheme guards against signature substitution attempts by Olive. So in this setup, Alice creates a BIB with the protected data block as its security target, then creates a BCB whose security targets are both the BIB and the protected data block 🫶
8.2.3. Topology Attacks 🗺️
If Olive is in an OPA position within the delay-tolerant network, she can influence how bundles that reach her pass through the network 🦋 When she gets a bundle that must be routed elsewhere, she has three options: not forward it, forward it as intended, or forward it to one or more specific nodes in the network. Main character behavior, but make it villain 😈
Attacks that reroute bundles through the network are basically a special case of the modification attacks above, where the attacker is changing fields in the primary block. BPSec can't encrypt the primary block's contents, so other methods have to be used to prevent this. Those methods MAY include requiring BIBs for primary blocks, using encapsulation, or otherwise strategically manipulating primary block data. The details of any such mitigation are specific to the deploying network's implementation and are outside the scope of this document 📦
Routing rules and policies can also help enforce particular traffic flows to prevent topology attacks 🧚 They might use some features BPSec provides, but defining them is beyond the scope of this specification 💜
8.2.4. Message Injection 💉
Olive can also generate brand-new bundles and send them into the DTN whenever she wants 😤 These bundles can be either 1) copies or slight modifications of bundles she's seen before (aka a replay attack), or 2) totally new bundles built from the Bundle Protocol, BPSec, or other bundle-related protocols. Her goals can vary, but she might be targeting the Bundle Protocol or the application-layer protocols it carries. The target could also be the storage and compute power of the nodes running the bundle or application protocols, like a denial of service that floods the storage of the store-and-forward mechanism, or a computation that processes bundles and blocks other stuff from happening 🌊
BPSec relies on cipher suite capabilities to stop replay or forged message attacks 🔒 A BCB used with appropriate crypto mechanisms MAY provide replay protection under certain circumstances. Another option is to augment the application data itself with mechanisms that assert data uniqueness, then protect it with a BIB, a BCB, or both along with other block data. In that case, the receiving node can validate the uniqueness of the data ✨
For example, a BIB can validate the integrity of a bundle's primary block, which includes a timestamp and lifetime for the bundle ⏰ If a bundle is replayed outside its lifetime, the replay fails because the bundle gets discarded 🗑️ Similarly, extra blocks, like the Bundle Age, can be signed and validated to catch replay attacks. And finally, security context parameters within BIBs and BCBs MAY include anti-replay mechanisms like session identifiers, nonces, and dynamic passwords, as supported by network characteristics 🎟️
9. Security Context Considerations 🎀
9.1. Mandating Security Contexts 📜
Okay, so networking scenarios and node capabilities are super diverse, and BPSec can be used in all of them 🌈 That means one single security context mandated for every possible BPSec implementation probably isn't feasible. A security context that's perfect for a resource-constrained node with limited connectivity might be totally wrong for a well-resourced, well-connected node 🙃
That doesn't mean BPSec gets used in a network with no security contexts at all, though. Interoperability and default behavior still matter 💅 Network designers MUST identify the minimal set of security contexts their network needs for its functions. For example, a default set of security contexts could be created for use over the terrestrial Internet, and any BPSec implementation communicating over the terrestrial Internet could be required to support them 🌍
To make sure implementations can talk to each other, all BPSec implementations MUST support at least the current mandatory security context(s) defined in IETF Standards Track RFCs 🤝 As of this writing, the BP mandatory security context is specified in [RFC9173], but the mandatory security contexts might change over time through the usual IETF processes. Changes are likely if flaws are found in the applicable crypto algorithms, for example 🔍
Beyond that, BPSec implementations need to support the security contexts required by the BP networks they're deployed in 📡
If a node is a gateway between two or more networks, the BPSec implementation at that node needs to support the union of security contexts mandated in those networks 🌉
BPSec was designed to allow a diversity of security contexts and for new contexts to be defined over time 🦄 Using different security contexts doesn't change the BPSec protocol itself. Defining a new security context MUST adhere to the requirements of such contexts as presented in this section and generally in this specification 📝
Implementers should keep an eye on the state of security context specifications to check for future updates and replacements 👀💖
9.2. Identification and Configuration 🎀
Okay bestie, every security block has to say which security context it's using, so each security context MUST be uniquely identifiable 🪪, and it MAY use parameters to customise itself ✨.
To keep the number of security contexts down in a network, designers should make them customisable through security context parameters 🧚. For example, one security context could be tied to a single cipher suite, and parameters could tweak it for different key lengths and different key management options. That way you don't need a brand-new context for every single option 🫶.
A single security context can be used for more than one security service 🦋, so a security context identifier MAY be used with a BIB, with a BCB, or with any other BPSec-compliant security block. The definition of a security context MUST identify which security services may be used with it, how security context parameters are interpreted for the security operation being supported, and which security results are produced for each security service. It has to be all spelled out 💅.
Network operators decide how many security contexts exist in a system, plus their type and configuration 👑. Networks that change fast might have just a few contexts, each loaded with lots of parameters. For more stable networks, or ones that really need confidentiality, you can define more contexts, with each one supporting few, if any, parameters 🌸.
+=============+============+=======================================+
| Context | Parameters | Definition |
| Type | | |
+=============+============+=======================================+
| Key | Encrypted | AES-GCM-256 cipher suite with |
| Exchange | Key, IV | provided ephemeral key encrypted with |
| AES | | a predetermined key encryption key |
| | | and cleartext initialization vector. |
+-------------+------------+---------------------------------------+
| Pre-Shared | IV | AES-GCM-256 cipher suite with |
| Key AES | | predetermined key and predetermined |
| | | key-rotation policy. |
+-------------+------------+---------------------------------------+
| Out-of-Band | None | AES-GCM-256 cipher suite with all |
| AES | | info predetermined. |
+-------------+------------+---------------------------------------+
Table 1: Security Context Examples9.3. Authorship 💖
Developers and implementers should think about the wide range of performance and conditions in networks where the Bundle Protocol (and therefore BPSec) will run 🌈. The delay and capacity of DTNs can vary a LOT, so developers should consider these conditions to better describe where a context will operate or be vulnerable, and pick contexts with that reality in mind. There are some key differences that might limit how much a security context can borrow from cipher suites and tech built for more reliable networks 🥺:
- Data Lifetime: Depending on the application environment, bundles may persist on the network for extended periods of time, perhaps even years. Cryptographic algorithms should be selected to ensure protection of data against attacks for a length of time reasonable for the application. ⏳
- One-Way Traffic: Depending on the application environment, it is possible that only a one-way connection may exist between two endpoints, or if a two-way connection does exist, the round-trip time may be extremely large. This may limit the utility of session key generation mechanisms, such as Diffie-Hellman, as a two-way handshake may not be feasible or reliable. 🛤️
- Opportunistic Access: Depending on the application environment, a given endpoint may not be guaranteed to be accessible within a certain amount of time. This may make asymmetric cryptographic architectures that rely on a key distribution center or other trust center impractical under certain conditions. 🌙
When developing security contexts for use with BPSec, the following information SHOULD be considered for inclusion in these specifications 📝.
- Security Context Parameters: Security contexts MUST define their parameter Ids, the data types of those parameters, and their CBOR encoding.
- Security Results: Security contexts MUST define their security result Ids, the data types of those results, and their CBOR encoding.
- New Canonicalizations: Security contexts may define new canonicalization algorithms as necessary.
- Ciphertext Size: Security contexts MUST state whether their associated cipher suites generate ciphertext (to include any authentication information) that is of a different size than the input plaintext.
- If a security context does not wish to alter the size of the plaintext, it should place overflow bytes and authentication tags in security result fields.
- Block Header Information: Security contexts SHOULD include block header information that is considered to be immutable for the block. This information MAY include the block type code, block number, CRC type, and CRC field (if present or if missing and unlikely to be added later), and possibly certain block processing control flags. Designers should input these fields as additional data for integrity protection when these fields are expected to remain unchanged over the path the block will take from the security source to the security acceptor. Security contexts considering block header information MUST describe expected behavior when these fields fail their integrity verification. 🔐
- Handling CRC Fields: Security contexts may include algorithms that alter the contexts of their security target block, such as the case when encrypting the block-type-specific data of a target block as part of a BCB confidentiality service. Security context specifications SHOULD address how preexisting CRC type and CRC value fields be handled. For example, a BCB security context could remove the plaintext CRC value from its target upon encryption and replace or recalculate the value upon decryption. 🧮
10. Defining Other Security Blocks 🧩
Other Security Blocks (OSBs) can be defined and used on top of the security blocks in this specification ✨. BIB, BCB, and any future OSBs can coexist within a bundle and can be considered in conformance with BPSec if all of the following requirements are met by any future identified security blocks:
- OSBs MUST NOT reuse any enumerations identified in this specification, to include the block type codes for BIB and BCB. 🚫
- An OSB definition MUST state whether it can be the target of a BIB or a BCB. The definition MUST also state whether the OSB can target a BIB or a BCB.
- An OSB definition MUST provide a deterministic processing order in the event that a bundle is received containing BIBs, BCBs, and OSBs. This processing order MUST NOT alter the BIB and BCB processing orders identified in this specification.
- An OSB definition MUST provide a canonicalization algorithm if the default algorithm for non-primary-block canonicalization cannot be used to generate a deterministic input for a cipher suite. This requirement can be waived if the OSB is defined so as to never be the security target of a BIB or a BCB.
- An OSB definition MUST NOT require any behavior of a BPSec BPA that is in conflict with the behavior identified in this specification. In particular, the security processing requirements imposed by this specification must be consistent across all BPSec BPAs in a network. 🤝
- The behavior of an OSB when dealing with fragmentation must be specified and MUST NOT lead to ambiguous processing states. In particular, an OSB definition should address how to receive and process an OSB in a bundle fragment that may or may not also contain its security target. An OSB definition should also address whether an OSB may be added to a bundle marked as a fragment. 🧩
Additionally, policy considerations for the management, monitoring, and configuration associated with blocks SHOULD be included in any OSB definition 📋.
NOTE: The burden of showing compliance with processing rules is placed upon the specifications defining new security blocks, and the identification of such blocks shall not, alone, require maintenance of this specification. 💅
11. IANA Considerations 🌷
This specification includes fields that require registries managed by IANA.
11.1. Bundle Block Types 📮
This specification allocates two block types from the existing "Bundle Block Types" registry defined in [RFC6255].
+=======+=======================+===============+
| Value | Description | Reference |
+=======+=======================+===============+
| 11 | Block Integrity | This document |
+-------+-----------------------+---------------+
| 12 | Block Confidentiality | This document |
+-------+-----------------------+---------------+
Table 2: Additional Entries for the "Bundle
Block Types" RegistryThe "Bundle Block Types" registry notes whether a block type is meant for use in BP version 6, BP version 7 (BPv7), or both. The two block types defined in this specification are meant for use with BPv7 🦋.
11.2. Bundle Status Report Reason Codes 🎀
okay so this spec grabs five reason codes from the existing "Bundle Status Report Reason Codes" registry, which is defined in [RFC6255] 💅 these are the new entries getting added, all pointing back to Section 7.1 of this document ✨
+============+=======+============================+================+
| BP Version | Value | Description | Reference |
+============+=======+============================+================+
| 7 | 12 | Missing security operation | This document, |
| | | | Section 7.1 |
+------------+-------+----------------------------+----------------+
| 7 | 13 | Unknown security operation | This document, |
| | | | Section 7.1 |
+------------+-------+----------------------------+----------------+
| 7 | 14 | Unexpected security | This document, |
| | | operation | Section 7.1 |
+------------+-------+----------------------------+----------------+
| 7 | 15 | Failed security operation | This document, |
| | | | Section 7.1 |
+------------+-------+----------------------------+----------------+
| 7 | 16 | Conflicting security | This document, |
| | | operation | Section 7.1 |
+------------+-------+----------------------------+----------------+
Table 3: Additional Entries for the "Bundle Status Report Reason
Codes" Registry11.3. Security Context Identifiers 🔥
BPSec has a Security Context Identifier field, and IANA made a brand new registry for it called "BPSec Security Context Identifiers" 🧚 Starting values are listed below.
The registration policy for this registry is Specification Required (see [RFC8126]) 🦋
The value range is a signed 16-bit integer 💜
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| < 0 | Reserved | This document |
+-------+-------------+---------------+
| 0 | Reserved | This document |
+-------+-------------+---------------+
Table 4: "BPSec Security Context
Identifier" RegistryNegative security context identifiers are reserved for local/site-specific uses. 🌙 The use of 0 as a security context identifier is for nonoperational testing purposes only. 🙈
12. References 📚
12.1. Normative References 🌸
[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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
2011, <https://www.rfc-editor.org/info/rfc6255>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[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>.
[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>.12.2. Informative References 🌈
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgments 🫶
the following people contributed technical material, use cases, and super useful thoughts on the overall approach to this security spec: Scott Burleigh of the IPNGROUP, Angela Hennessy of the Laboratory for Telecommunications Sciences, Amy Alford and Cherita Corbett of the Johns Hopkins University Applied Physics Laboratory (JHU/APL), and Angela Dalton of AMD Research 👑
Benjamin Kaduk of Akamai Technologies also gave a detailed technical review, which made the spec stronger and more precise ✨😭
Authors' Addresses 🦋
Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
United States of America
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu
Kenneth McKeever
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
United States of America
Phone: +1 443 778 2237
Email: Ken.McKeever@jhuapl.edu📦 where this page comes from
- ietf: rfc9172 2022-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms