Given the nature of DTN applications, it is expected that bundles may traverse a variety of environments and devices that each pose unique security risks and requirements on the implementation of security within BPSec. For this reason, it is important to introduce key threat models and describe the roles and responsibilities of the BPSec protocol in protecting the confidentiality and integrity of the data against those threats. This section provides additional discussion on security threats that BPSec will face and describes how BPSec security mechanisms operate to mitigate these threats.
The threat model described here is assumed to have a set of capabilities identical to those described by the Internet Threat Model in [RFC 3552
], but the BPSec threat model is scoped to illustrate threats specific to BPSec operating within DTN environments; therefore, it focuses on on-path attackers (OPAs). In doing so, it is assumed that the delay-tolerant network (or significant portions of the delay-tolerant network) are completely under the control of an attacker.
BPSec was designed to protect against OPA threats that may have access to a bundle during transit from its source, Alice, to its destination, Bob. An OPA node, Olive, is a noncooperative node operating on the delay-tolerant network between Alice and Bob that has the ability to receive bundles, examine bundles, modify bundles, forward bundles, and generate bundles at will in order to compromise the confidentiality or integrity of data within the delay-tolerant network. There are three classes of OPA nodes that are differentiated based on their access to cryptographic material:
Olive has not been provisioned within the secure environment and only has access to cryptographic material that has been publicly shared.
Olive is within the secure environment; therefore, Olive has access to cryptographic material that has been provisioned to Olive (i.e., KM) as well as material that has been publicly shared.
Olive is a privileged node within the secure environment; therefore, Olive has access to cryptographic material that has been provisioned to Olive, Alice, and/or Bob (i.e., KM, KA, and/or KB) as well as material that has been publicly shared.
If Olive is operating as a privileged node, this is tantamount to compromise; BPSec does not provide mechanisms to detect or remove Olive from the delay-tolerant network or BPSec secure environment. It is up to the BPSec implementer or the underlying cryptographic mechanisms to provide appropriate capabilities if they are needed. It should also be noted that if the implementation of BPSec uses a single set of shared cryptographic material for all nodes, a legitimate node is equivalent to a privileged node because KM
. 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., KM
). In this case, Olive is able to impersonate traffic as either Alice or Bob, respectively, which means that traffic to and from that node can be decrypted and encrypted, respectively. Additionally, messages may be signed as originating from one of the endpoints.
Once Olive has received a bundle, she is able to examine the contents of that bundle and attempt to recover any protected data or cryptographic keying material from the blocks contained within. The protection mechanism that BPSec provides against this action is the BCB, which encrypts the contents of its security target, providing confidentiality of the data. Of course, it should be assumed that Olive is able to attempt offline recovery of encrypted data, so the cryptographic mechanisms selected to protect the data should provide a suitable level of protection.
When evaluating the risk of eavesdropping attacks, it is important to consider the lifetime of bundles on DTN. Depending on the network, bundles may persist for days or even years. Long-lived bundles imply that the data exists in the network for a longer period of time and, thus, there may be more opportunities to capture those bundles. Additionally, the implication is that long-lived bundles store information within that remains relevant and sensitive for long enough that, once captured, there is sufficient time to crack encryption associated with the bundle. If a bundle does persist on the network for years and the cipher suite used for a BCB provides inadequate protection, Olive may be able to recover the protected data either before that bundle reaches its intended destination or before the information in the bundle is no longer considered sensitive.
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.
As a node participating in the delay-tolerant network between Alice and Bob, Olive will also be able to modify the received bundle, including non-BPSec data such as the primary block, payload blocks, or block processing control flags as defined in [RFC 9171
]. Olive will be able to undertake activities including modification of data within the blocks, replacement of blocks, addition of blocks, or removal of blocks. Within BPSec, both the BIB and BCB provide integrity-protection mechanisms to detect or prevent data manipulation attempts by Olive.
The BIB provides that protection to another block that is its security target. The cryptographic mechanisms used to generate the BIB should be strong against collision attacks, and Olive should not have access to the cryptographic material used by the originating node to generate the BIB (e.g., KA
). If both of these conditions are true, Olive will be unable to modify the security target or the BIB, and thus she cannot lead Bob to validate the security target as originating from Alice.
Since BPSec security operations are implemented by placing blocks in a bundle, there is no in-band mechanism for detecting or correcting certain cases where Olive removes blocks from a bundle. If Olive removes a BCB, but keeps the security target, the security target remains encrypted and there is a possibility that there may no longer be sufficient information to decrypt the block at its destination. If Olive removes both a BCB (or BIB) and its security target, there is no evidence left in the bundle of the security operation. Similarly, if Olive removes the BIB, but not the security target, there is no evidence left in the bundle of the security operation. In each of these cases, the implementation of BPSec must be combined with policy configuration at endpoints in the network that describe the expected and required security operations that must be applied on transmission and that are expected to be present on receipt. This or other similar out-of-band information is required to correct for removal of security information in the bundle.
A limitation of the BIB may exist within the implementation of BIB validation at the destination node. If Olive is a legitimate node within the delay-tolerant network, the BIB generated by Alice with KA
can be replaced with a new BIB generated with KM
and forwarded to Bob. If Bob is only validating that the BIB was generated by a legitimate user, Bob will acknowledge the message as originating from Olive instead of Alice. Validating a BIB indicates only that the BIB was generated by a holder of the relevant key; it does not provide any guarantee that the bundle or block was created by the same entity. In order to provide verifiable integrity checks, the BCB should require an encryption scheme that is Indistinguishable under adaptive Chosen Ciphertext Attack (IND-CCA2) secure. Such an encryption scheme will guard against signature substitution attempts by Olive. In this case, Alice creates a BIB with the protected data block as the security target and then creates a BCB with both the BIB and protected data block as its security targets.
If Olive is in an OPA position within the delay-tolerant network, she is able to influence how any bundles that come to her may pass through the network. Upon receiving and processing a bundle that must be routed elsewhere in the network, Olive has three options as to how to proceed: not forward the bundle, forward the bundle as intended, or forward the bundle to one or more specific nodes within the network.
Attacks that involve rerouting the bundles throughout the network are essentially a special case of the modification attacks described in this section, one where the attacker is modifying fields within the primary block of the bundle. Given that BPSec cannot encrypt the contents of the primary block, alternate methods must be used to prevent this situation. These methods may include requiring BIBs for primary blocks, using encapsulation, or otherwise strategically manipulating primary block data. The details of any such mitigation technique are specific to the implementation of the deploying network and are outside of the scope of this document.
Furthermore, routing rules and policies may be useful in enforcing particular traffic flows to prevent topology attacks. While these rules and policies may utilize some features provided by BPSec, their definition is beyond the scope of this specification.
Olive is also able to generate new bundles and transmit them into the delay-tolerant network at will. These bundles may be either 1) copies or slight modifications of previously observed bundles (i.e., a replay attack) or 2) entirely new bundles generated based on the Bundle Protocol, BPSec, or other bundle-related protocols. With these attacks, Olive's objectives may vary, but may be targeting either the Bundle Protocol or application-layer protocols conveyed by the Bundle Protocol. The target could also be the storage and computing capabilities of the nodes running the bundle or application-layer protocols (e.g., a denial of service to flood on the storage of the store-and-forward mechanism or a computation that would process the bundles and perhaps prevent other activities).
BPSec relies on cipher suite capabilities to prevent replay or forged message attacks. A BCB used with appropriate cryptographic mechanisms may provide replay protection under certain circumstances. Alternatively, application data itself may be augmented to include mechanisms to assert data uniqueness and then be protected with a BIB, a BCB, or both along with other block data. In such a case, the receiving node would be able to validate the uniqueness of the data.
For example, a BIB may be used to validate the integrity of a bundle's primary block, which includes a timestamp and lifetime for the bundle. If a bundle is replayed outside of its lifetime, then the replay attack will fail as the bundle will be discarded. Similarly, additional blocks, such as the Bundle Age, may be signed and validated to identify replay attacks. Finally, security context parameters within BIBs and BCBs may include anti-replay mechanisms such as session identifiers, nonces, and dynamic passwords as supported by network characteristics.