RFC 6257
Bundle Security Protocol Specification
Part 1 of 16 🎀
Bundle Security Protocol Specification ✨
Okay bestie, so this is RFC 6257, titled Bundle Security Protocol Specification 🦋. It's an Experimental document from the Internet Research Task Force (IRTF), published in May 2011 (ISSN 2070-1721). The authors are S. Symington from The MITRE Corporation, S. Farrell from Trinity College Dublin, and H. Weiss and P. Lovell from SPARTA, Inc. 💅 Its title block doesn't list anything it obsoletes or updates, so it's a standalone vibe.
Abstract
Okay, the big idea: this doc defines the bundle security protocol 🔐, which gives the Bundle Protocol data integrity and confidentiality services. The protection is split up, so the bundle payload and any extra data that rides along inside the bundle each get their own capabilities. It also covers a bunch of security considerations, including some policy options 🧠.
The doc is a product of the Delay-Tolerant Networking Research Group, and that group reviewed it. No objections to publishing it as an RFC were raised 🙌.
Status of This Memo
Not an Internet Standards Track spec, babe 🫶. It's published so people can examine it, try out experimental implementations, and evaluate it.
It defines an Experimental Protocol for the Internet community. It comes from the IRTF, which publishes research and development results related to the Internet. Those results might not be ready for deployment, so keep that in mind 🌸. This RFC reflects the consensus of the Delay-Tolerant Networking Research Group of the IRTF. Anything the IRSG approves for publication is not a candidate for any level of Internet Standard, and you can read Section 2 of RFC 5741 for the details 📚.
For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6257 🔗.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜.
Table of Contents
1. Introduction ....................................................4
1.1. Related Documents ..........................................4
1.2. Terminology ................................................5
2. Security Blocks .................................................8
2.1. Abstract Security Block ....................................9
2.2. Bundle Authentication Block ...............................13
2.3. Payload Integrity Block ...................................15
2.4. Payload Confidentiality Block .............................16
2.5. Extension Security Block ..................................20
2.6. Parameters and Result Fields ..............................21
2.7. Key Transport .............................................23
2.8. PIB and PCB Combinations ..................................24
3. Security Processing ............................................25
3.1. Nodes as Policy Enforcement Points ........................26
3.2. Processing Order of Security Blocks .......................26
3.3. Security Regions ..........................................29
3.4. Canonicalization of Bundles ...............................31
3.5. Endpoint ID Confidentiality ...............................37
3.6. Bundles Received from Other Nodes .........................38
3.7. The At-Most-Once-Delivery Option ..........................39
3.8. Bundle Fragmentation and Reassembly .......................40
3.9. Reactive Fragmentation ....................................41
3.10. Attack Model .............................................42
4. Mandatory Ciphersuites .........................................42
4.1. BAB-HMAC ..................................................42
4.2. PIB-RSA-SHA256 ............................................43
4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB ............................44
4.4. ESB-RSA-AES128-EXT ........................................48
5. Key Management .................................................51
6. Default Security Policy ........................................51
7. Security Considerations ........................................53
8. Conformance ....................................................55
9. IANA Considerations ............................................56
9.1. Bundle Block Types ........................................56
9.2. Ciphersuite Numbers .......................................56
9.3. Ciphersuite Flags .........................................56
9.4. Parameters and Results ....................................57
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................591. Introduction 🌈
This doc defines the security features for the Bundle Protocol [DTNBP], made for delay-tolerant networks 🧚. Its whole purpose is to deliver Delay-Tolerant Networking (DTN) security services.
Okay so the Bundle Protocol lives in DTNs that stitch together multiple networks. Some of those networks are stressed, meaning they can have intermittent and possibly unpredictable loss of connectivity, long or variable delays, asymmetric data rates, and high error rates 😭. The Bundle Protocol is there to keep things interoperable across all that chaos. It sits on top of underlay-network-specific convergence layers, which sit on top of network-specific lower layers. That setup lets an application in one network talk to an application in another network, and the DTN spans both 🌸.
Security is a huge deal for the Bundle Protocol 💅. Since it runs over those stressed underlying networks, the DTN needs protection from unauthorized use, and that stress makes it harder to find mechanisms that secure the protocol. On top of that, DTNs are very likely to be deployed where part of the network could get compromised. So you're dealing with the usual confidentiality, integrity, and availability problems, just with extra spice 🔥.
Different security processing applies to the payload and to the extension blocks that might come with it in a bundle, and different rules apply to different extension blocks 🎀.
This doc describes both the base Bundle Security Protocol (BSP) and a set of mandatory ciphersuites. A ciphersuite is a specific bundle of cryptographic algorithms and implementation rules that work together to deliver certain security services 🔐✨.
The Bundle Security Protocol only applies, by definition, to nodes that implement it. Those are called "security-aware" nodes 👑. There MAY be other nodes in the DTN that don't implement BSP. Everyone can interoperate, with one catch: BSP security operations can only happen at security-aware nodes 🦋.
1.1. Related Documents
If you want the full picture, read this doc alongside these other DTN documents 📚:
"Delay-Tolerant Networking Architecture" [DTNarch] defines the architecture for delay-tolerant networks, but it doesn't go into security much at all.
The DTN Bundle Protocol [DTNBP] defines the format and processing of the blocks used to implement the Bundle Protocol, leaving out the security-specific blocks defined here 💖.
1.2. Terminology ✨
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read the way [RFC2119] explains 🎀
we're also gonna define some terms so nobody gets confused, bestie 🫶
- source - the bundle node where a bundle starts its journey 🌸
- destination - the bundle node that the bundle is ultimately headed to 💌
- forwarder - the bundle node that forwarded the bundle on its most recent hop 🦋
- intermediate receiver or "next hop" - the neighboring bundle node that a forwarder passes a bundle to 🧚
- path - the ordered sequence of nodes a bundle goes through from source to destination 🗺️
so this figure is adapted from figure 1 in the Bundle Protocol Specification [DTNBP] 👀 it shows four bundle nodes (BN1, BN2, BN3, and BN4) chilling above some transport layer(s). there are also three different transport and network protocols (T1/N1, T2/N2, and T3/N3) in the picture too 💅
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+
| | | |
|<-- An Internet --->| |<--- An Internet --->|
| | | |
BN = "Bundle Node" as defined in the Bundle Protocol Specification
Figure 1: Bundle Nodes Sit at the Application Layer
of the Internet Modelso here's the tea ☕ BN1 starts a bundle and forwards it to BN2. then BN2 passes it to BN3, and BN3 passes it to BN4. BN1 is the source and BN4 is the destination 🎯 BN1 is the first forwarder and BN2 is the first intermediate receiver. then BN2 becomes the forwarder and BN3 becomes the intermediate receiver. then BN3 is the last forwarder, and BN4 is the last intermediate receiver AND the destination, so it's giving main character energy 👑
and if BN2 creates its own bundle (like a bundle status report or a custodial signal) and sends it to BN3, and then to BN4, then BN2 is the source of that bundle (and also the first forwarder) and BN4 is the destination (and also the final intermediate receiver) 🌈
now for the security-specific DTN terms 🔐
- security-source - a bundle node that adds a security block to a bundle 🧁
- security-destination - a bundle node that processes a security block of a bundle 🍓
- security path - the ordered sequence of security-aware nodes that a bundle goes through from the security-source to the security-destination 🛤️
back to Figure 1 again 👀
if BN1 makes a bundle and also gives it a security block, then BN1 is the security-source for that block AND the source of the bundle 💖
if the bundle that starts at BN1 gets a security block from BN2 instead, then BN2 is the security-source for that block, even though BN1 is still the source 🫠
if BN1 gives the bundle a security block that's meant to be processed by BN3, then BN1 is the security-source and BN3 is the security-destination for that block. the security path for this block is BN1 to BN3 🛣️
a bundle MAY have multiple security blocks 🎀 the security-source of a bundle for one security block MAY be the same as or different from the security-source for a different security block in that bundle. same deal for the security-destination: for each of the bundle's security blocks, it MAY be the same or different. so the security paths for the different blocks MAY be, and often will be, different 🦋
okay now the overlap situation 😭 if BN1 gives the bundle a security block meant for BN3, and BN2 adds its own security block with security-destination BN4, then the security paths for those two blocks overlap, but not completely. we talk more about this problem in Section 3.3 🙈
as required in [DTNBP], forwarding nodes MUST transmit blocks in a bundle in the same order they were received 💅 this applies to ALL DTN nodes, not just the ones doing security processing ✨ blocks in a bundle MAY be added or deleted according to the applicable specification. but the blocks that are both received AND transmitted MUST be transmitted in the same order that they were received 🔁
if a node isn't security-aware, it forwards the security blocks in the bundle unchanged, unless the bundle's block processing flags say otherwise 🫶 if a network has some nodes that aren't security-aware, then the block processing flags SHOULD be set so that security blocks don't get thrown out at those nodes just because they can't be processed there 🗑️🚫 other than that, non-security-aware nodes are transparent relay points and are invisible as far as security processing is concerned 👻
the block sequence also tells you the order in which certain important actions affected the bundle. so the sequence in which actions MUST occur is what produces the bundle at its destination 🎬
2. Security Blocks 🔐
there are four types of security blocks that MAY be included in a bundle 💜 they are the Bundle Authentication Block (BAB), the Payload Integrity Block (PIB), the Payload Confidentiality Block (PCB), and the Extension Security Block (ESB) ✨
- BAB - used to make sure the bundle's authenticity and integrity along a single hop, from forwarder to intermediate receiver 🛡️ security blocks only get processed at security-aware nodes, so a "single hop" from one security-aware forwarder to the next security-aware intermediate receiver might actually be more than one real hop 🌍 we get into that more in Section 2.2.
- PIB - used to make sure the payload's authenticity and integrity, from the PIB security-source that creates the PIB, all the way to the PIB security-destination that verifies the PIB authenticator 🔎 the authentication info in the PIB MAY (if the ciphersuite allows) be verified by any node in between the PIB security-source and PIB security-destination that has the cryptographic keys and revocation status information needed to do it 🗝️
- PCB - indicates that the payload has been encrypted, in whole or in part, at the PCB security-source, to protect the bundle content while it's in transit to the PCB security-destination 🔒
okay the layering part is important 🧅 since a BAB protects a bundle on a "hop-by-hop" basis, and other security blocks MAY be protecting over several hops or end-to-end, whenever both are present, the BAB MUST form the "outer" layer of protection. that means the BAB MUST always be calculated and added to the bundle AFTER all the other security blocks have been calculated and added 🎀
PIB and PCB both protect the payload, so they're considered "payload-related" for the purposes of the security discussion in this doc 💖 other blocks are "non-payload" blocks. and of course, the primary block is unique and has its own separate rules 👑
- ESB - provides security for non-payload blocks in a bundle 🧸 so ESB is NOT applied to PIBs or PCBs, and of course it's not appropriate for either the payload block or the primary block 🙅♀️
each of the security blocks uses the Canonical Bundle Block Format defined in the Bundle Protocol Specification 📦 so every security block is made up of these elements:
- Block-type code
- Block processing control flags
- Block EID-reference list (OPTIONAL)
- Block data length
- Block-type-specific data fields
since the four security blocks have most fields in common, we can make the description of each security block's Block-type-specific data fields shorter. we do this by defining an abstract security block (ASB) first, and then specifying each real block in terms of which fields are present or absent in an ASB 🧠 ngl that's genius. just note that no bundle ever contains an actual ASB, since it's only a specification artifact 🦄
2.1. Abstract Security Block
okay bestie, the Abstract Security Block (ASB) is the foundation of every security block 💖 Lots of the fields below use the SDNV type from [DTNBP]. SDNV stands for Self-Delimiting Numeric Value ✨
An ASB has the following fields, some mandatory and some optional 🎀:
- Block-type code (one byte) - same as in all bundle protocol blocks except the primary bundle block. The block-type codes for the security blocks are:
- BundleAuthenticationBlock - BAB:
0x02 - PayloadIntegrityBlock - PIB:
0x03 - PayloadConfidentialityBlock - PCB:
0x04 - ExtensionSecurityBlock - ESB:
0x09
- BundleAuthenticationBlock - BAB:
- Block processing control flags (SDNV) - defined the same way as in all bundle protocol blocks except the primary bundle block (see the Bundle Protocol Specification [DTNBP]). SDNV encoding is explained in the Bundle Protocol too. There are no general constraints on the block processing control flags, but a few specific requirements come up later 🌸
- EID-references - a composite field defined in [DTNBP] that holds references to one or two endpoint identifiers (EIDs). Whether this field is there is shown by the "Block contains an EID-reference field" (EID_REF) bit in the block processing control flags. If one or more references are present, the flags in the ciphersuite ID field (described below) say which ones 🦋
If no EID fields are present, then the composite field itself MUST be omitted entirely and the EID_REF bit MUST be unset. A count field of zero is not permitted.
- The possible EIDs are:
- (OPTIONAL) Security-source - specifies the security-source for the block. If this is left out, the source of the bundle is assumed to be the security-source unless stated otherwise 🧚
- (OPTIONAL) Security-destination - specifies the security-destination for the block. If this is left out, the destination of the bundle is assumed to be the security-destination unless stated otherwise 💜
If two EIDs are present, security-source comes first and security-destination comes second.
- Block data length (SDNV) - same as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol.
- Block-type-specific data fields, which go like this:
- Ciphersuite ID (SDNV)
- Ciphersuite flags (SDNV)
- (OPTIONAL) Correlator - when more than one related block is inserted, this field MUST have the same value in each related block instance. It is encoded as an SDNV. Check the note in Section 3.8 about correlator values in bundle fragments 👑
- (OPTIONAL) Ciphersuite-parameters - a compound field made of the next two items:
- Ciphersuite-parameters length - the length of the following Ciphersuite-parameters data field, encoded as an SDNV.
- Ciphersuite-parameters data - parameters used with the ciphersuite in use, for example a key identifier or initialization vector (IV). See Section 2.6 for a list of potential parameters and their encoding rules. Exactly which parameters go in this field is defined as part of the ciphersuite specification.
- (OPTIONAL) Security-result - a compound field made of the next two items:
- Security-result length - contains the length of the next field and is encoded as an SDNV.
- Security-result data - contains the results of the appropriate ciphersuite-specific calculation (for example a signature, Message Authentication Code (MAC), or ciphertext block key).
Okay so the diagram looks like it's 32-bit, but that's just to make things easier to picture 🙈 Apart from the "type" field, every field is variable in length.
+----------------+----------------+----------------+----------------+
| type | flags (SDNV) | EID-ref list(comp) |
+----------------+----------------+----------------+----------------+
| length (SDNV) | ciphersuite (SDNV) |
+----------------+----------------+----------------+----------------+
| ciphersuite flags (SDNV) | correlator (SDNV) |
+----------------+----------------+----------------+----------------+
|params len(SDNV)| ciphersuite params data |
+----------------+----------------+----------------+----------------+
|res-len (SDNV) | security-result data |
+----------------+----------------+----------------+----------------+
Figure 2: Abstract Security Block StructureSome ciphersuites are specified in Section 4, which also lays out the rules that MUST be satisfied by ciphersuite specifications. Additional ciphersuites MAY be defined in separate specifications. Ciphersuite IDs that aren't specified are reserved. Bundle Security Protocol implementations get to decide which ciphersuites they support, as long as they follow the requirements in Section 4. It is RECOMMENDED that implementations which allow additional ciphersuites permit ciphersuite ID values at least up to and including 127, and they MAY decline to allow larger ID values 🌈
The ciphersuite flags field is laid out as shown in Figure 3. For each optional field, setting its flag to one means the field is there, and zero means it's missing 💅 Right now there are five flags defined for this field. To keep things simple, they're shown as if they were pulled out of a single-byte SDNV. Future additions might make the field grow to the left, so (like the flags fields in [DTNBP]) the bit positions below are numbered from the right, not the way standard RFCs number bits, which is from the left ⭐
- src - bit 4 shows whether the EID-reference field of the ASB has the optional reference to the security-source.
- dest - bit 3 shows whether the EID-reference field of the ASB has the optional reference to the security-destination.
- parm - bit 2 shows whether or not the ciphersuite-parameters length and ciphersuite-parameters data fields are present.
- corr - bit 1 shows whether or not the ASB has an optional correlator.
- res - bit 0 shows whether or not the ASB has the security-result length and security-result data fields.
- bits 5-6 are reserved for future use.
Bit Bit Bit Bit Bit Bit Bit
6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+
| reserved | src |dest |parm |corr |res |
+-----+-----+-----+-----+-----+-----+-----+
Figure 3: Ciphersuite FlagsLittle extra vocab 📚 If the block is a PIB, then when we say PIB-source, we mean the security-source for the PIB, shown by the EID-reference in the EID-reference field. In the same way, "PCB-dest" means the security-destination of the PCB, also shown by an EID reference. Let's look at Figure 1 again 🦋 Say the bundle that starts at BN1 gets a Payload Confidentiality Block (PCB) from BN1, protected with a key that BN3 holds, and BN1 also gives it a Payload Integrity Block (PIB). Then BN1 is both the PCB-source and the PIB-source of the bundle, and BN3 is the PCB-destination of the bundle 🫶
The correlator field links several related instances of a security block together 🔗 This is how you can put a BAB holding the ciphersuite information at the "front" of a (probably big) bundle, and another correlated BAB holding the security-result at the "end". That way even very memory-constrained nodes can process the bundle and verify the BAB 😭 PIB and PCB have similar use cases with multiple related instances, as we'll see below.
The ciphersuite specification MUST make it clear whether or not multiple block instances are allowed, and if they are, under what conditions. Some ciphersuites can leave flexibility to the implementation, while others might require a fixed number of instances 🍓
For convenience, we say "first block" for the initial block in a group of correlated blocks, or for the single block if there are no others in the set. There can be several unrelated groups in a bundle, each with only one block or more than one, and each one has its own "first block" 🌸
2.2. Bundle Authentication Block ✨
okay so this section is about what a BAB looks like in two different setups 🎀 one is the single-BAB version where one block has literally everything, and the other uses two related BAB instances. one goes "up front" with the ciphersuite, and the other follows the payload and carries the security-result (like a MAC) 🦋
For the case where a single BAB is used:
- The
block-type codefield value MUST be0x02. - The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite 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. 🫶
- The ciphersuite ID MUST be documented as a hop-by-hop authentication-ciphersuite that requires one instance of the BAB.
- The
correlatorfield MUST NOT be present. 🙈 - The
ciphersuite-parametersfield MAY be present, if so specified in the ciphersuite specification. - An EID-reference to the
security-sourceMAY be present. Thesecurity-sourcecan also be specified as part of key-information described in Section 2.6 or another block such as the Previous-Hop Insertion Block [PHIB]. Thesecurity-sourcemight also be inferred from some implementation-specific means such as the convergence layer. 🌸 - An EID-reference to the
security-destinationMAY be present and is useful to ensure that the bundle has been forwarded to the correct next-hop node. 🧚 - The
security-resultMUST be present, because it is effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle, as specified in the ciphersuite definition. 🔥
For the case using two related BAB instances, the first instance is as defined above, except the ciphersuite ID MUST be documented as a hop-by-hop authentication ciphersuite that requires two instances of the BAB. In addition, the correlator MUST be present and the security-result length and security-result fields MUST be absent. The second instance of the BAB MUST have the same correlator value present and MUST contain security-result length and security-result data fields. The other optional fields MUST NOT be present. Typically, this second instance of a BAB will be the last block of the bundle. 💜
The details of key transport for BAB are specified by the particular ciphersuite. In the absence of conflicting requirements, the following should be noted by implementors:
- The key-information item in Section 2.6 is OPTIONAL, and if not provided, then the key SHOULD be inferred from the source-destination tuple, being the previous key used, a key created from a key-derivation function, or a pre-shared key. 🔑
- If all the nodes are security-aware, the capabilities of the underlying convergence layer might be useful for identifying the
security-source. 🌈 - Depending upon the key mechanism used, bundles can be signed by the sender, or authenticated for one or more recipients, or both. ✨
2.3. Payload Integrity Block 💅
okay so a PIB is basically an ASB with some extra rules on top 👑 here they are:
- The
block-type codevalue MUST be0x03. - The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite 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. 🫶
- The ciphersuite ID MUST be documented as an end-to-end authentication-ciphersuite or as an end-to-end error-detection-ciphersuite. 🎀
- The
correlatorMUST be present if the ciphersuite requires that more than one related instance of a PIB be present in the bundle. ThecorrelatorMUST NOT be present if the ciphersuite only requires one instance of the PIB in the bundle. 🙈 - The
ciphersuite-parametersfield MAY be present. 🌸 - An EID-reference to the
security-sourceMAY be present. Thesecurity-sourcecan also be specified as part of key-information described in Section 2.6. 🧚 - An EID-reference to the
security-destinationMAY be present. 🦋 - The
security-resultis effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle. As in the case of the BAB, this field MUST be present if thecorrelatoris absent. If more than one related instance of the PIB is required, then this is handled in the same way as described for the BAB above. 🔥 - The ciphersuite MAY process less than the entire original bundle payload. This might be because it is defined to process some subset of the bundle, or perhaps because the current payload is a fragment of an original bundle. For whatever reason, if the ciphersuite processes less than the complete, original bundle payload, the
ciphersuite-parametersof this block MUST specify which bytes of the bundle payload are protected. 💜
For some ciphersuites (e.g., those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information can be checked at any hop on the way to the security-destination that has access to the required keying information. This possibility is further discussed in Section 3.6. 🌈
The use of a generally available key is RECOMMENDED if custodial transfer is employed, and all nodes SHOULD verify the bundle before accepting custody. 👑
Most asymmetric PIB ciphersuites will use the PIB-source to indicate who the signer is and will not require the PIB-dest field, because the key needed to verify the PIB authenticator will be a public key associated with the PIB-source. ✨
2.4. Payload Confidentiality Block 🔐
okay so this is the part where the secret-keeping happens 🤫 A typical confidentiality ciphersuite encrypts the payload with a randomly generated bundle encrypting key (BEK) 🗝️, then uses a key-information item in the PCB security-parameters to carry that BEK, encrypted under some long-term key encryption key (KEK) or a well-known public key 💌. If neither the destination nor the security-destination can resolve the key for decryption, the key-information item in the ciphersuite-parameters field can also say which decryption key can recover the BEK 🔑. If the bundle already has PIBs and/or PCBs, these SHOULD also be encrypted with that same BEK, which is the "super-encryption" thing I'll explain in a sec 🪆 The encrypted block then gets wrapped in a brand new PCB that takes the original block's exact spot in the bundle 🎁
It is strongly RECOMMENDED that a data integrity mechanism be used alongside confidentiality, and that encryption-only ciphersuites NOT be used 🛡️ AES-Galois/Counter Mode (AES-GCM) meets this requirement, and it's giving security-first energy 💅 The "authentication tag" or "integrity check value" gets stored in the security-result instead of being tacked onto the end of the payload like in some other protocols. Why? Because, as we'll see, it's really important that the size of the payload doesn't change 📏
The payload gets encrypted "in-place," which means after encryption the payload block's payload field holds ciphertext, not plaintext 🙈 The payload block processing control flags are left unmodified ✨
The whole "in-place" thing exists so that bundle payload fragmentation and reassembly, and custody transfer, can keep working without having to know whether encryption happened at all, and if so, how many times 🧩
Fragmentation, reassembly, and custody transfer get messed up when the payload size changes, because it becomes ambiguous which byte range of the original payload is actually sitting in any given fragment 💥 So ciphersuites SHOULD place any payload expansion, like authentication tags (integrity check values) and any padding made by a block-mode cipher, into an integrity check value item in the security-result field (see Section 2.6) of the confidentiality block 🎀
Payload super-encryption is allowed, which means encrypting a payload that's already been encrypted, maybe more than once 🪆 Ciphersuites SHOULD define super-encryption so that, as well as re-encrypting the payload, it also protects the parameters of the earlier encryption.
Failure to do so may represent a vulnerability in some circumstances. 😬 This one is genuinely a big deal, bestie, so don't skip it!
Confidentiality normally applies to the payload, and possibly to additional blocks too 🌈 It is RECOMMENDED to apply a Payload Confidentiality ciphersuite to non-payload blocks only if these SHOULD be super-encrypted with the payload. If super-encryption of the block is not desired, then protection of the block SHOULD be done using the Extension Security Block mechanism rather than PCB 🦋
Multiple related PCB instances are required if both the payload and the PIBs and PCBs in the bundle are going to be encrypted. These multiple PCB instances need correlators so they can find each other, since the key-information is only provided in the first PCB 🔗
There are also situations where you get more than one PCB instance but they're not "related" in the way that needs correlators 🙃 One example: a payload gets encrypted for more than one security-destination so it stays robust even when routing is uncertain. The payload is encrypted with a BEK, and several PCBs carry that BEK encrypted under different KEKs, one for each destination. These multiple PCB instances are not "related" and SHOULD NOT contain correlators 🌸
The ciphersuite MAY apply different rules to confidentiality for non-payload blocks 🧚
A PCB is an ASB with the following additional restrictions 👑
- The block-type code value MUST be
0x04. - The block processing control flags value can be set to whatever values are required by local policy, except that a PCB "first block" MUST have the "replicate in every fragment" flag set. This flag SHOULD NOT be set otherwise. Ciphersuite 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. ⚠️
- The ciphersuite ID MUST be documented as a confidentiality ciphersuite.
- The correlator MUST be present if there is more than one related PCB instance. The correlator MUST NOT be present if there are no related PCB instances.
- If a correlator is present, the key-information MUST be placed in the PCB "first block".
- Any additional bytes generated as a result of encryption and/or authentication processing of the payload SHOULD be placed in an "integrity check value" field (see Section 2.6) in the security-result of the first PCB.
- The
ciphersuite-parametersfield MAY be present. - An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6.
- An EID-reference to the security-destination MAY be present.
- The security-result MAY be present and normally contains fields such as an encrypted bundle encryption key, authentication tag, or the encrypted versions of bundle blocks other than the payload block. 🎁
The ciphersuite MAY process less than the entire original bundle payload, either because the current payload is a fragment of the original bundle or just because it's defined to process some subset 🧩 Whatever the reason, if the ciphersuite processes less than the complete, original bundle payload, the "first" PCB MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected 📍
PCB ciphersuites MUST specify which blocks are to be encrypted. That specification MAY be flexible and depend on block type, security policy, various data values, and other inputs, but it MUST be deterministic. The determination of whether or not a block is to be encrypted MUST NOT be ambiguous 🎯
As was the case for the BAB and PIB, if the ciphersuite requires more than one instance of the PCB, then the "first block" MUST contain any optional fields (e.g., security-destination, etc.) that apply to all instances with this correlator. These MUST be contained in the first instance and MUST NOT be repeated in other correlated blocks. Fields that are specific to a particular instance of the PCB MAY appear in that PCB. For example, security-result fields MAY (and probably will) be included in multiple related PCB instances, with each result being specific to that particular block. Similarly, several PCBs might each contain a ciphersuite-parameters field with an IV specific to that PCB instance 🥰
Put another way 🫶 when confidentiality will generate multiple blocks, it MUST create a "first" PCB with the required ciphersuite ID, parameters, etc., as specified above. Typically this PCB will show up early in the bundle. This "first" PCB holds the parameters that apply to the payload and also to the other correlated PCBs. The correlated PCBs follow the "first" PCB and MUST NOT repeat the ciphersuite-parameters, security-source, or security-destination fields from the first PCB. The correlated PCBs don't need to follow immediately after the "first" PCB, and they probably won't 🙃 Each correlated block, encapsulating an encrypted PIB or PCB, sits at the same place in the bundle as the original PIB or PCB 📦
A ciphersuite MUST NOT mix payload data and a non-payload block in a single PCB 🚫
Even if a to-be-encrypted block has the "discard" flag set, whether or not the PCB's "discard" flag is set is an implementation/policy decision for the encrypting node 🤷♀️ (Fun fact: the "discard" flag is more properly called the "Discard if block can't be processed" flag 💀)
Any existing EID-list in the to-be-encapsulated original block stays exactly as-is, and gets copied to become the EID-list for the replacing block. The encapsulation process MUST NOT replace or remove the existing EID-list entries. This is critically important for correctly updating entries at the security-destination 🌟
At the security-destination, either the specific destination or the bundle-destination, all of the processes above get reversed 🔄 The payload is decrypted "in-place" using the salt, IV, and key values in the first PCB, including verification using the ICV. These values are described in Section 2.6. Each correlated PCB is processed at that same destination too, using the salt and key values from the first PCB along with the block-specific IV item. The encapsulated block item in the security-result gets decrypted and validated, using also the tag that SHOULD have been appended to the ciphertext of the original block data. If validation succeeds, the resulting plaintext, which is the entire content of the original block, replaces the PCB at the same place in the bundle. The block type reverts to that of the original block from before encapsulation, and the other block-specific data fields return to their original values 🦋 Implementors, this "replacement" step requires delicate stitchery 🧵 because the EID-list contents in the decapsulated block are invalid. As noted above, the EID-list references in the original block were preserved in the "replacing" PCB, and they'll have been updated as necessary as the bundle toured the DTN 🚌 The references from the PCB MUST replace the references within the EID-list of the newly decapsulated block.
Caveat implementor. 🫣💖
2.5. Extension Security Block ✨
Okay bestie, extension security blocks (ESBs) are the ones that guard the parts of a bundle that aren't the payload 🎀 ESBs MUST NOT be used for the primary block or payload, including payload-related security blocks (PIBs and PCBs). No exceptions, no vibes-based workarounds 💅
Sometimes you wanna protect certain parts of a bundle differently than the payload. One example is bundle metadata that tells you what kind of data is in the payload but not the actual payload details, as described in [DTNMD]. Literally so useful 😭🧚
ESBs are typically used for confidentiality protection 🔐 You can make an integrity-only ciphersuite, but the block protection isn't transparent and makes getting to the data way harder 🙈 So for simplicity, we're gonna talk about a confidentiality ciphersuite 💖
The protection mechanisms in ESBs are super similar to the other security blocks, with two big differences 👑
- different key values are used (using the same key as that for payload would defeat the purpose)
- the block is not encrypted or super-encrypted with the payload
A typical ESB ciphersuite encrypts the extension block using a randomly generated ephemeral key 🦋 It then uses the key-information item in the security-parameters field to carry that key, encrypted with some long-term key encryption key (KEK) or well-known public key. If neither the destination nor the security-destination resolves the key to use for decryption, the key-information item in the ciphersuite-parameters field can also be used to indicate the decryption key that the BEK can be recovered with 🌸
It is strongly RECOMMENDED that a data integrity mechanism be used alongside confidentiality, and that encryption-only ciphersuites NOT be used. AES-GCM satisfies this requirement 🫶
The ESB sits in the bundle in the same position as the block it's protecting. So the entire original block gets processed (encrypted, etc.) and encapsulated in a "replacing" ESB-type block, which shows up at the same sequential position as the original block 🍓 The processed data goes in the security-result field.
The process gets reversed at the security-destination, where the recovered plaintext block replaces the ESB that encapsulated it ✨ Processing of EID-list entries, if any, is described in Section 2.4, and this MUST be followed in order to correctly recover EIDs. Don't skip it, bestie 🙏
An ESB is an ASB with the following additional restrictions:
- The block type is
0x09. - Ciphersuite flags indicate which fields are present in this block. Ciphersuite 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.
- EID-references MUST be stored in the EID-reference list.
- The security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6. If neither is present, then the bundle-source is used as the security-source.
- The security-destination MAY be present. If not present, then the bundle-destination is used as the security-destination.
The security-parameters MAY optionally contain a block-type code field to indicate the type of the encapsulated block. Since this replicates a field in the encrypted portion of the block, it is a slight security risk, so its use is therefore OPTIONAL.
Heads up: that block-type code copies something that's already encrypted, so it's a slight security risk. That's why it's OPTIONAL 🙈💀
2.6. Parameters and Result Fields
Various ciphersuites include several items in the security-parameters and/or security-result fields. Which items MAY appear is defined by the particular ciphersuite description. A ciphersuite MAY support several instances of the same type within a single block 🌈
Each item is represented as a type-length-value. Type is a single byte indicating which item this is. Length is the count of data bytes to follow, and is an SDNV-encoded integer. Value is the data content of the item 🧁
Item types are:
0: reserved
1: initialization vector (IV)
2: reserved
3: key-information
4: fragment-range (offset and length as a pair of SDNVs)
5: integrity signature
6: unassigned
7: salt
8: PCB integrity check value (ICV)
9: reserved
10: encapsulated block
11: block type of encapsulated block
12 - 191: reserved
192 - 250: private use
251 - 255: reservedThe following descriptions apply to how these items are used for all ciphersuites. Additional characteristics are noted in the discussion for specific suites 💜
- initialization vector (IV): random value, typically eight to sixteen bytes.
- key-information: key material encoded or protected by the key management system, used to transport an ephemeral key protected by a long-term key. This item is discussed further in Section 2.7.
- fragment-range: pair of SDNV values (offset then length) specifying the range of payload bytes to which a particular operation applies. It's termed "fragment-range" since that's its typical use, even though sometimes it describes a subset range that is not a fragment. The offset value MUST be the offset within the original bundle, which might not be the offset within the current bundle if the current bundle is already a fragment.
- integrity signature: result of BAB or PIB digest or signing operation. This item is discussed further in Section 2.7.
- salt: an IV-like value used by certain confidentiality suites.
- PCB integrity check value (ICV): output from certain confidentiality ciphersuite operations, used at the destination to verify that the protected data has not been modified.
- encapsulated block: result of a confidentiality operation on certain blocks. It contains the ciphertext of the block and MAY also contain an integrity check value appended to the ciphertext. It MAY also contain padding if required by the encryption mode. Used for non-payload blocks only.
- block type of encapsulated block: block-type code for a block that has been encapsulated in ESB.
2.7. Key Transport
This specification endeavors to keep the security protocol and key management separate 🎀 However, the two interact when key-information and so on get transferred from the security-source to the security-destination. The point of the separation is to make it easy to use a variety of key management systems without having to tailor a ciphersuite to each one individually ✨
The key management process deals with things like long-term keys, specifiers for long-term keys, certificates for long-term keys, and integrity signatures using long-term keys. The ciphersuite itself SHOULD NOT require knowledge of these. Separation is improved if it treats them as opaque entities to be handled by the key management process 🦋
The key management process deals specifically with the content of two of the items defined in Section 2.6: key-information (item type 3) and integrity signature (item type 5). The ciphersuite MUST define the details and format for these items. To facilitate interoperability, it is strongly RECOMMENDED that implementations use the appropriate definitions from the Cryptographic Message Syntax (CMS) [RFC5652] and related RFCs 🫶
Many situations will require several pieces of key-information. Again, ciphersuites MUST define whether they accept these packed into a single key-information item and/or separated into multiple instances of key-information. For interoperability, it is RECOMMENDED that ciphersuites accept these packed into a single key-information item, and they MAY additionally choose to accept them sent as separate items 👑🔥
2.8. PIB and PCB Combinations 🎀
Okay so, nodes can mix and match PIB and PCB however they want 💅 The correlator value is what keeps each application of security services separate, so they don't get tangled up. Since PIB and PCB cover the payload and ESB covers the non-payload blocks, combining ESB with PIB and/or PCB is not considered here 🙈
There are some obvious security problems that can pop up when you stack multiple services 😭 For example, if we encrypted a payload but left a PIB security-result with a signature in the clear, somebody could confirm payload guesses. Not it 💀
We can't, in general, prevent all of these problems, since we can't assume that every ciphersuite definition takes account of every other ciphersuite definition. BUT we can limit the risk by requiring that any ciphersuite that applies to one instance of a PIB or PCB MUST be applied to all instances with the same correlator 🔒
Here are the PIB and PCB combinations we envisage as being useful to support ✨
- Encrypted tunnels -- a single bundle MAY be encrypted many times en route to its destination 🌈 Clearly, it has to be decrypted an equal number of times, but you can picture each encryption as stepping into yet another layer of tunnel. This is supported by using multiple instances of PCB, with the payload encrypted multiple times, "in-place". Depending upon the ciphersuite definition, other blocks can and should be encrypted, as discussed above and in Section 2.4, so that parameters are protected in the case of super-encryption 🧚
- Multiple parallel authenticators -- a single security-source might wish to protect the integrity of a bundle in multiple ways 🦋 This could be required if the bundle's path is unpredictable and if various nodes might be involved as security-destinations. Similarly, if the security-source cannot determine in advance which algorithms to use, then using all of them might be reasonable. This would result in uses of PIB that, presumably, all protect the payload, and which cannot in general protect one another. Note that this logic can also apply to a BAB, if the unpredictable routing happens in the convergence layer, so we also envisage support for multiple parallel uses of BAB 👑
- Multiple sequential authenticators -- if some security-destination requires assurance about the route that bundles have taken, it might insist that each forwarding node add its own PIB 🛣️ More likely, though, outbound "bastion" nodes would be configured to sign bundles as a way of letting the sending "domain" take accountability for the bundle. In this case, the various PIBs will likely be layered, so that each protects the earlier applications of PIB 🍓
- Authenticated and encrypted bundles -- a single bundle MAY require both authentication and confidentiality 🫶 Some specifications first apply the authenticator and then encrypt the payload and authenticator. As noted previously, where the authenticator is a signature, there are security reasons for this ordering. (See the
PCB-RSA-AES128-PAYLOAD-PIB-PCBciphersuite defined in Section 4.3.) Others apply the authenticator after encryption, that is, to the ciphertext. This ordering is generally RECOMMENDED, since it minimizes attacks that, in some cases, can lead to recovery of the encryption key 🔥
There are, no doubt, other valid ways to combine PIB and PCB instances, but these are the "core" set supported in this specification. Having said that, as you'll see, the mandatory ciphersuites defined here are quite specific and restrictive in terms of limiting the flexibility offered by the correlator mechanism. This is primarily designed to keep this specification as simple as possible while still supporting the scenarios above 💖
3. Security Processing ✨
This section is all about the security side of bundle processing 🔐
3.1. Nodes as Policy Enforcement Points 👑
All nodes are REQUIRED to have and enforce their own configurable security policies, whether these policies are explicit or default, as defined in Section 6 💅
All nodes serve as Policy Enforcement Points (PEPs) insofar as they enforce policies that MAY restrict the permissions of bundle nodes to inject traffic into the network 🚧 Policies MAY apply to traffic that originates at the current node, traffic that terminates at the current node, and traffic that is to be forwarded by the current node to other nodes. If a particular transmission request, originating either locally or remotely, satisfies the node's policy or policies and is therefore accepted, then an outbound bundle can be created and dispatched 🚀 If not, then in its role as a PEP, the node will not create or forward a bundle. Error handling for such cases is currently considered out of scope for this document 🙈
Policy enforcing code MAY override all other processing steps described here and elsewhere in this document. For example, it is valid to implement a node that always attempts to attach a PIB. Similarly, it is also valid to implement a node that always rejects all requests that imply the use of a PIB 💀
Nodes MUST consult their security policy to determine the criteria that a received bundle ought to meet before it will be forwarded 🧐 These criteria MUST include a determination of whether or not the received bundle MUST include a valid BAB, PIB, PCB, or ESB. If the bundle does not meet the node's policy criteria, then the bundle MUST be discarded and processed no further. In this case, a bundle status report indicating the failure MAY be generated 📝
The node's policy MAY call for the node to add or subtract some security blocks 🧩 For example, it might require that the node attempt to encrypt (parts of) the bundle for some security-destination, or that it add a PIB. If the node's policy requires a BAB to be added to the bundle, it MUST be added last, so that the calculation of its security-result MAY take into consideration the values of all other blocks in the bundle 🫶
3.2. Processing Order of Security Blocks
okay so the processing order is literally everything 😭🎀 security actions only complete successfully if they happen in the right order. In general, the actions performed at the originating node MUST be executed in the reverse sequence at the destination. There are some variations and exceptions, and I'll flag those below 🫶
The sequence is kept by the ordering of security blocks in the bundle. That's why blocks MUST NOT be rearranged at forwarding nodes, whether or not those nodes support the security protocols 🚫 The only blocks that count for this ordering are the primary and payload blocks, plus the PIB and PCB security blocks themselves. All other extension blocks, ESBs included, get ignored when figuring out the processing order 💅
Security blocks get added and removed in a last-in-first-out (LIFO) manner, with the top of the stack sitting right after the primary block 📚 A newly created bundle only has the primary and payload blocks, so the stack is empty. When security actions get requested, blocks get pushed onto the stack right after the primary block. Early actions end up with blocks close to the payload, and later actions have blocks nearer the primary block ✨ Each action only deals with the blocks that exist in the bundle at that moment. So the first block added only processes the payload and primary blocks, the next one might process the first block if it wants, plus the payload and primary, and so on. The last block added can process all the blocks 👑
When the bundle arrives, the whole thing gets reversed. Security processing starts at the top of the stack, right after the primary block. The security actions run, the block gets popped, and processing moves on to the next security block until only the payload and primary blocks are left 🌸
Real life is messier than this 🙄 but it's still a super helpful starting framework for getting how bundle security works 🧚
The first issue is very common and easy to handle 💖 A bundle may be sent indirectly, so it needs several forwarding hops to finally arrive. Security processing happens at each node, assuming that node supports bundle security. For the following discussion, we assume a bundle is created and that confidentiality, then payload integrity, and finally bundle authentication get applied to it. The block sequence would therefore be primary-BAB-PIB-PCB-payload. Traveling from source to destination goes through one intermediate node, so the trip is two hops 🦋
When the bundle hits the intermediate node, receive processing validates the BAB and pops it from the stack. However, the PIBs and PCBs have the final destination as their security-destination, so they can't be processed and removed yet. The intermediate node then starts the send process with the four remaining blocks. The outbound processing adds any security blocks required by local policy, and these get pushed onto the stack right after the primary block, ahead of the PIB. In this example, the intermediate node adds a PIB as a signature that the bundle has passed through the node 🖊️
At the destination, receive processing first handles the intermediate node's PIB and pops it. Next is the originator's PIB, also popped. Finally comes the originator's confidentiality block, which lets the payload be decrypted so the bundle can be handled for delivery 🎉
DTNs are likely to be more complex 🌈 The security policy for a node specifies the security requirements for a bundle. The policy may cause one or more security operations to be applied to the bundle at the current node, each with its own security-destination. Applying policy at subsequent nodes might cause additional security operations, each with a security-destination. The list of security-destinations in the security blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of nodes that MUST be visited en route to the bundle-destination 🗺️
The bundle security scheme does not deal with security paths that overlap partially but not completely 🙅 The security policy for a node MUST avoid specifying, for a bundle, a security-destination that causes a conflict with any existing security-destination in that bundle. More on this in Section 3.3 👀
The second issue is about reversibility of certain security process actions 🔁 In general, the actions fall into two categories: those that do not affect other parts of the bundle, and those that are fully reversible. Creating a bundle signature, for example, doesn't change the bundle content except for the result. The encryption done as part of confidentiality processing does change the bundle, but the reverse processing at the destination restores the original content 🔐
The third category is where the bundle content changes slightly and in a non-destructive way, but there's no mechanism to reverse the change 😬 The simplest example is adding an EID-reference to a security block. The addition of the reference adds the text to the bundle's dictionary. That text may also be used by other references, so removing the block and this specific EID-reference does not remove the text from the dictionary. This is no big deal for the "sequential" or "wrapping" security schemes described above, but it does cause failures with "parallel" authentication mechanisms. Solutions for this problem are implementation specific and typically involve multi-pass processing, where blocks are added at one stage and the security-results are calculated at a later stage of the overall process 🔧
Certain ciphersuites have sequence requirements for their correct operation, most notably the bundle authentication ciphersuites 🔐 Processing for bundle authentication is required to happen after all other sending operations, and before any receive operations at the next-hop node. So it follows that BABs MUST always be pushed onto the stack after all others 🫶
Heads up: although we describe the security block list as a stack, some blocks are placed after the payload and are therefore not part of the stack 👀
The BundleAuthentication ciphersuite #1 ("BA1") needs a second, correlated block to contain the security-result. This block is placed after the payload, usually as the last block in the bundle. We can still apply the stack rules to these blocks by specifying that they be added to the end of the bundle at the same time that their "owner" or "parent" block is pushed on the stack. In fact, they form a stack beginning at the payload but growing in the other direction 🪄 Also, not all blocks in the main stack have a corresponding entry in the trailing stack. The only blocks that MUST follow the payload are those mandated by ciphersuites as correlated blocks for holding a security-result. No other blocks are required to follow the payload block, and it is NOT RECOMMENDED that they do so 🙅♀️
ESBs are effectively placeholders for the blocks they encapsulate. Since those don't form part of the processing sequence described above, ESBs don't either 🧸 ESBs MAY be correlated, though, so the "no reordering" requirement applies to them as well 💜
3.3. Security Regions 🗺️
Okay so every security block has its own security path (remember the Figure 1 discussion 🦋), and the paths for different blocks are often totally different. Main character energy for each one 💅
BABs are always for a single hop, so those restricted paths literally never cause conflict ✨
The paths for PIBs and PCBs are often from bundle-source to bundle-destination, which gives end-to-end protection 🫶. A bundle-source-to-bundle-destination path likewise never causes a problem 💖
Another super common vibe is gateway-to-gateway protection of traffic between two sub-networks, called "tunnel-mode" 🚇.
Look at Figure 1 and the simplified version in Figure 4. We can think of BN2 and BN3 as gateways connecting the two sub-networks labeled "An internet". As long as they provide security for the BN2-BN3 path, all is well 🌸. Things go sideways when BN2 adds blocks with BN4 as the security-destination, while the originating node BN1 has already created blocks with BN3 as security-destination. Now we've got two paths, and neither one is a subset of the other 😭
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
<------------- BN1 to BN3 path ------------>
<------------- BN2 to BN4 path ------------>
Figure 4: Overlapping Security PathsThis scenario should be prevented by node BN2's security policy being aware of the already existing block with BN3 as the security-destination. Honestly this is the key part 🙈 This policy SHOULD NOT specify a security-destination that is further distant than any existing security-destination.
Let's look at the case where the security concern is data integrity, so the blocks are PIBs. BN1 creates one ("PIa") along with the new bundle, and BN2 pushes its own PIB "PIb" on the stack, with security-destination BN4. When this bundle arrives at BN3, the bundle blocks are:
primary - PIb - PIa - payloadBlock PIb is not destined for this node BN3, so it has to be forwarded. BN3 is the security-destination for block PIa, so after validation it should be removed from the bundle. However, that will invalidate the PIb signature when the block is checked at the final destination. The PIb signature includes the primary block, PIb itself, PIa and the payload block, so PIa MUST remain in the bundle 🧠 This is why security blocks are treated as a stack, and add/remove operations are permitted only at the top-of-stack.
It gets even messier if the security concern is confidentiality and PCBs are employed, using the confidentiality ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, BN1 would encrypt the bundle with BN3 as security-destination. BN2 would then create an overlapping security path by super-encrypting the payload and encapsulating the PC3 block for security-destination BN4. BN3 forwards all the blocks without change. BN4 decrypts the payload from its super-encryption and decapsulates the PC3 block, only to find that it should have been processed earlier. Assuming that BN4 has no access to BN3's key store, BN4 has no way to decrypt the bundle and recover the original content 😱
As mentioned above, authors of security policy need to be careful to make sure their policies don't cause overlaps. These guidelines should prove helpful 📝
- The originator of a bundle can always specify the bundle-destination as the security-destination, and should be cautious about doing otherwise.
- In the "tunnel-mode" scenario where two sub-networks are connected by a tunnel through a network, the gateways can each specify the other as security-destination, and should be cautious about doing otherwise.
- BAB is never a problem because it is always only a single hop.
- PIB for a bundle without PCB will usually specify the bundle-destination as security-destination.
- PIB for a bundle containing a PCB should specify as its security-destination the security-destination of the PCB (outermost PCB if there are more than one).
3.4. Canonicalization of Bundles 🪞
Okay, this part is serious but also kind of iconic. To verify a signature or MAC on a bundle, the exact same bits, in the exact same order, MUST be input to the calculation upon verification as were input when the original signature or MAC value was first computed 🔐 So a node MUST NOT change the encoding of any URI [RFC3986] in the dictionary field. For example, it can't change the DNS part of some HTTP URL from lower case to upper case 🙅♀️ Because bundles MAY be modified while in transit (either correctly or due to implementation errors), a canonical form of any given bundle (that contains a BAB or PIB) MUST be defined 💜
This section defines the bundle canonicalization algorithms used in the Section 4.1 and 4.2 ciphersuites. Other ciphersuites can use these or define their own canonicalization procedures ✨
3.4.1. Strict Canonicalization 💎
The first algorithm permits no changes at all to the bundle between the security-source and the security-destination. It's mainly intended for use in BAB ciphersuites. This algorithm conceptually catenates all blocks in the order presented, but omits all security-result data fields in blocks of this ciphersuite type. So when a BAB ciphersuite specifies this algorithm, we omit all BAB security-results for all BAB ciphersuites. When a PIB ciphersuite specifies this algorithm, we omit all PIB security-results for all PIB ciphersuites. All security-result length fields are still included, even though their corresponding security-result data fields are omitted 🫧
Notes:
- In the above, we specify that security-result data is omitted. This means that no bytes of the security-result data are input. We do not set the security-result length to zero. Instead, we assume that the security-result length will be known to the module that implements the ciphersuite before the security-result is calculated, and require that this value be in the security-result length field even though the security-result data itself will be omitted.
- The
resbit of the ciphersuite ID, which indicates whether or not the security-result length and security-result data field are present, is part of the canonical form. - The value of the block data length field, which indicates the length of the block, is also part of the canonical form. Its value indicates the length of the entire bundle when the bundle includes the security-result data field.
- BABs are always added to bundles after PIBs, so when a PIB ciphersuite specifies this strict canonicalization algorithm and the PIB is received with a bundle that also includes one or more BABs, application of strict canonicalization as part of the PIB security-result verification process requires that all BABs in the bundle be ignored entirely 🙈
3.4.2. Mutable Canonicalization
Okay, bestie, this one is the chill sibling of strict canonicalization 🦋. It's built to protect the parts of the bundle that SHOULD NOT be changed in transit 🔒. So it deliberately skips the mutable stuff, because those fields are allowed to shift around while the bundle travels.
The plan is to build a canonical form of the primary block, then stick it together with the security blocks (only PIBs and PCBs) and the payload blocks, in the same order they'll be sent 🌸. Every other block gets ignored, including ESBs, since there's no way to know if they'll change along the route 🙈. Short version: this protects the payload, the payload-related security blocks, and parts of the primary block 💖.
Lots of fields are stored as variable-length SDNVs. For this algorithm, they get unpacked into eight-byte fixed-width fields in network byte order ✨. Eight bytes was picked because implementations MAY handle bigger values as invalid, as noted in [DTNBP] 💅.
The canonical primary block is shown in Figure 5 🎀. It basically dereferences the dictionary block, fixes up lengths where needed, and ignores flags that MAY change in transit 🧚.
+----------------+----------------+----------------+----------------+
| Version | Processing flags (incl. COS and SRR) |
+----------------+----------------+---------------------------------+
| Canonical primary block length |
+----------------+----------------+---------------------------------+
| Destination endpoint ID length |
+----------------+----------------+---------------------------------+
| |
| Destination endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Source endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Source endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Report-to endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Report-to endpoint ID |
| |
+----------------+----------------+----------------+----------------+
| |
+ Creation Timestamp (2 x SDNV) +
| |
+---------------------------------+---------------------------------+
| Lifetime |
+----------------+----------------+----------------+----------------+
Figure 5: The Canonical Form of the Primary Bundle BlockHere's what each field in Figure 5 means 👑:
- Version: the single-byte value from the primary block.
- Processing flags: this one's an SDNV in the primary block and includes the COS and SRR fields. For canonicalization, it gets unpacked into a fixed-width field, then some bits get masked out. The unpacked field is ANDed with
0x0000 0000 0007 C1BE, which zeroes out all the reserved bits and the "bundle is a fragment" bit 🙈. - Canonical primary block length: a four-byte value holding the length (in bytes) of this structure, in network byte order.
- Destination endpoint ID length and value: the length (four-byte value, network byte order) and the value of the destination endpoint ID from the primary bundle block. The URI is just copied from the relevant part(s) of the dictionary block and is NOT canonicalized itself 😭. The dictionary entries have "null-terminators", but those aren't counted in the length or in the canonicalization 🍓.
- Source endpoint ID length and value: handled the same way as the destination.
- Report-to endpoint ID length and value: handled the same way as the destination.
- Creation timestamp (2 x SDNV) and lifetime (SDNV): copied straight from the primary block, with the SDNV values shown as eight-byte unpacked values ✨.
- Fragment offset and total application data unit length: ignored, same as the "bundle is a fragment" bit mentioned above. If the payload data being canonicalized is less than the complete, original bundle payload, the offset and length are specified in the security-parameters 🌈.
For non-primary blocks that get included in canonicalization, the block processing control flags value is the unpacked SDNV with the reserved and mutable bits masked to zero 💜. The unpacked value gets ANDed with 0x0000 0000 0000 0077, which zeroes the reserved bits and the "last block" flag ⭐. The "last block" flag gets ignored because BABs and other security blocks MAY be added for some parts of the journey but not others, so that bit might flip from hop to hop 🦋.
Endpoint ID references in security blocks get canonicalized using the dereferenced text form, in place of the reference pair 🫶. The reference count isn't included, and neither is the length of the endpoint ID text 💅.
The block-length is canonicalized as an eight-byte unpacked value in network byte order 🔥. If the payload data being canonicalized is smaller than the complete, original bundle payload, this field holds the size of the data being canonicalized (the "effective block") instead of the real size of the block 🧚.
Payload blocks are usually canonicalized as-is 🌸. The exception is when only part of the payload should be protected. In that case, only those bytes go into the canonical form, and extra ciphersuite-parameters are needed to say which part of the payload is protected (more on that below) ✨.
Security blocks are handled the same way, EXCEPT the ciphersuite will likely say the "current" security block's security-result field should NOT be counted in the canonical form 💀. This is different from strict canonicalization, because we might use mutable canonicalization to handle sequential signatures, so that signatures cover the earlier ones 🎀.
ESBs MUST NOT be included in the canonicalization 🙅♀️.
Notes 📝:
- The canonical form of the bundle is never transmitted. It's just a leftover artifact used as input to digesting 💖.
- We leave out the reserved flags because we can't tell whether they'll change in transit. If more flags get defined and need protecting, the masks above will have to be revised 🔧.
- Our URI encoding doesn't keep the null-termination convention from the dictionary field, and it doesn't split the scheme from the scheme-specific part (SSP) the way the dictionary does 🌸.
- The URI encoding will cause errors if any node rewrites the dictionary content (for example, changing the DNS part of an HTTP URL from lower case to upper case). This could happen without anyone meaning it, like when a bundle gets synced to disk with one piece of software and then read back and forwarded by a second one. Since there are no general rules for canonicalizing URIs (or IRIs), this might be an unavoidable source of integrity failures 😭.
- All SDNV fields here are canonicalized as eight-byte unpacked values in network byte order. Length fields are canonicalized as four-byte values in network byte order. Encoding doesn't need to be optimized, since these values are never sent over the network 🧚.
Now for the fragmentation drama 🎭. If a bundle gets fragmented BEFORE the PIB is applied, then the PIB only applies to a fragment and not the entire bundle. Even worse, that protected fragment could get fragmented again later, which would leave the verifier unable to tell which bytes the PIB actually covered 🙈. The same mess happens even without fragmentation if the ciphersuite allows protecting less than the entire, original bundle payload 💀.
So PIB ciphersuites that support applying a PIB to less than the complete, original bundle payload MUST specify, as part of the ciphersuite-parameters, exactly which bytes of the bundle payload are protected 🔒. When verification happens, only that specified range of payload bytes gets fed into PIB verification 💅. A ciphersuite is allowed to apply only to entire bundles and not to fragments 🌈. A ciphersuite MAY be specified to apply to only a portion of the payload, whether or not the payload is a fragment or the complete, original bundle payload ✨.
The same fragmentation problem hits PCB ciphersuites too 🎀. Ciphersuites that support applying confidentiality to fragments MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected 👑. When decrypting a fragment, only the specified bytes get processed 🦋. A confidentiality ciphersuite is also allowed to apply only to entire bundles and not to fragments 🫶.
This definition of mutable canonicalization assumes endpoint IDs are themselves immutable, so it's NOT suitable for environments where that assumption could break 😬.
Also, the canonicalization applies to a specific bundle and not a specific payload 💖. If a bundle gets forwarded in some way, the recipient can't verify the original integrity signature, because the source EID will be different, and possibly other fields too 😭.
The fix for either of these problems is to define and use a PIB ciphersuite that has an alternate version of mutable canonicalization any fields from the primary block 🔧.
3.5. Endpoint ID Confidentiality
Every bundle MUST contain a primary block that holds the source and destination endpoint IDs, and possibly other EIDs (in the dictionary field), and that block can NOT be encrypted 🔒. If endpoint ID confidentiality is required, bundle-in-bundle encapsulation can solve this in some cases 🧚.
Similarly, confidentiality requirements MAY also apply to other parts of the primary block (for example, the current-custodian), and that's handled in the same way 🌸✨.
3.6. Bundles Received from Other Nodes ✨
okay so when a bundle shows up from another node, the very first thing you do is check your security policy 🧐 Nodes implementing this specification SHALL consult their security policy to figure out whether that bundle is required by policy to carry a BAB. If there's no BAB and one isn't required, then BAB processing on that bundle is done, and it's ready for PIB/PCB/ESB handling or for delivery or forwarding 💅
If the bundle is supposed to have a BAB but doesn't, it MUST be discarded and processed no further 💀 Same deal if it's required to have a BAB but every single BAB points at a BAB security-destination that isn't the receiving node. Bye bye 👋
If the bundle is required to have a BAB and has one or more BABs that name the receiving node as the BAB security-destination (or that have no security-destination at all), then the value in the security-result field(s) of those BAB(s) MUST be verified according to the ciphersuite specification 🔍 If, across all of those BABs, either the BAB security source can't be figured out or the security-result check fails, the bundle has failed to authenticate, and it MUST be discarded and processed no further. But if any of the BABs present verify, or if a BAB wasn't required in the first place, the bundle is ready for further processing as decided by extension blocks and/or policy 🎀
BABs received in a bundle MUST be stripped before the bundle is forwarded. New BABs MAY be added as required by policy. Adding them MAY require correcting the last block field of the to-be-forwarded bundle, so don't forget that 🧚
Further processing of the bundle MUST take place in the order indicated by the various blocks, going from the primary block to the payload block, except where an applicable specification says otherwise 🦋
Now the PCB part, which is giving main character energy 👑 If the bundle has a PCB and the receiving node is the PCB-destination (either because the node is listed as the PCB-destination, or because it's listed as the bundle-destination and there's no PCB-dest), the node MUST decrypt the relevant parts of the bundle according to the ciphersuite specification. The PCB SHALL be deleted after that. If the relevant parts can't be decrypted (the decryption key can't be deduced or decryption fails), the bundle MUST be discarded and processed no further. In that case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated 📝 And if the PCB security-result included the ciphertext of a block other than the payload block, the recovered plaintext block MUST be placed in the bundle at the location the PCB was deleted from 🌸
Next up, PIBs 🔐 If the bundle has one or more PIBs for which the receiving node is the bundle's PIB-destination (either because the node is listed in the bundle's PIB-destination, or because it's listed as the bundle-destination and there's no PIB-dest), the node MUST verify the value in the PIB security-result field(s) according to the ciphersuite specification. If all the checks fail, the bundle has failed to authenticate, and the bundle SHALL be processed according to the security policy. A bundle status report indicating the failure MAY be generated. Otherwise, if the PIB verifies, the bundle is ready to be processed for delivery or forwarding. Before forwarding the bundle, the node SHOULD remove the PIB from the bundle, subject to the requirements of Section 3.2, unless it's likely that some downstream node will also be able to verify the PIB 🫶
If the bundle has a PIB and the receiving node is not the bundle's PIB-dest, the receiving node MAY attempt to verify the value in the security-result field. If it's able to check and the check fails, the node SHALL discard the bundle, and it MAY send a bundle status report indicating the failure 😭
Last one for this section: ESBs 🎁 If the bundle has an ESB and the receiving node is the ESB-destination (either because the node is listed as the bundle's ESB-destination, or because it's listed as the bundle-destination and there's no ESB-destination), the node MUST decrypt and/or decapsulate the encapsulated block according to the ciphersuite specification. The decapsulated block replaces the ESB in the bundle block sequence, which means the ESB is deleted ✨ If the content can't be decrypted (the decryption key can't be deduced or decryption fails), then the bundle MAY be discarded and processed no further, unless the security policy specifies otherwise. In that case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated 💖
3.7. The At-Most-Once-Delivery Option 🌈
An application MAY request (in an implementation-specific manner) that a node be registered as a member of an endpoint, and that received bundles destined for that endpoint be delivered to that application 🧚
This option is known as "at-most-once-delivery" 💅 If it's chosen, the application is saying it wants the node to check for duplicate bundles, discard duplicates, and deliver at most one copy of each received bundle to the application. If it's not chosen, the application is saying it wants the node to deliver every received bundle copy. So if this option is chosen, the node SHALL deliver at most one copy of each received bundle to the application. If the option isn't chosen, the node SHOULD, subject to policy, deliver all bundles 🍓
To make that happen, the node MUST look at the source/timestamp pair value of each complete (reassembled, if necessary) bundle it receives, and figure out whether this pair, which uniquely identifies a bundle, has been received before. If it has, the bundle is a duplicate. If it hasn't, the bundle is not a duplicate. The source/timestamp pair SHALL be added to the list of pair values already received by that node 🔁
Each node implementation MAY decide how long to keep its table of pair value state ⏳
3.8. Bundle Fragmentation and Reassembly 🧩
If a node needs to fragment a bundle and security services have been applied to that bundle, the fragmentation rules described in [DTNBP] MUST be followed. As defined there (and repeated here for completeness), only the payload MAY be fragmented. Security blocks, like all extension blocks, can never be fragmented 🙅 On top of that, the following security-specific processing is REQUIRED:
The security policy requirements for a bundle MUST be applied individually to all the bundles that result from a fragmentation event 🎀
If the original bundle contained a PIB, then each of the PIB instances MUST be included in some fragment 🔐
If the original bundle contained one or more PCBs, then any PCB instances containing a key-information item MUST have the "replicate in every fragment" flag set, which means they get replicated in every fragment. This is so the canonical block-sequence can be recovered during reassembly 🧠
If the original bundle contained one or more correlated PCBs that don't contain a key-information item, then each of these MUST be included in some fragment, but they SHOULD NOT be sent more than once. They MUST be placed in a fragment according to the fragmentation rules described in [DTNBP] 💫
Note: various fragments MAY have additional security blocks added at this or later stages, and it's possible that correlators will collide. To keep things unique, ciphersuites SHOULD include the fragment-offset of the fragment as a high-order component of the correlator. 🚨
3.9. Reactive Fragmentation 🦋
When a partial bundle has been received, the receiving node SHALL consult its security policy to see if it MAY fragment the bundle, turning the received portion into a bundle fragment for further forwarding. Whether or not reactive fragmentation is permitted SHALL depend on the security policy and on the ciphersuite used to calculate the BAB authentication information, if one is required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC (Hashed Message Authentication Code) ciphersuite defined in Section 4.1, don't accommodate reactive fragmentation, because the security-result in the BAB requires that the entire bundle be signed. It's conceivable, though, that a BAB ciphersuite could be defined so that multiple security-results are calculated, each on a different segment of a bundle, and those security-results could be interspersed between bundle payload segments so that reactive fragmentation could be accommodated 🧃)
If the bundle is reactively fragmented by the intermediate receiver and the BAB-ciphersuite is of an appropriate type (for example, one with multiple security-results embedded in the payload), the bundle MUST be fragmented immediately after the last security-result value in the partial payload that was received. Any data received after the last security-result value MUST be dropped 🚫
If a partial bundle is received at the intermediate receiver and is reactively fragmented and forwarded, only the part of the bundle that was not received MUST be retransmitted, though more of the bundle MAY be retransmitted. Before retransmitting a portion of the bundle, it SHALL be changed into a fragment. And if the original bundle included a BAB, the fragmented bundle MUST also, and its BAB SHALL be recalculated 🔄
This specification doesn't define any ciphersuite that can handle this reactive fragmentation case 🙈
An interesting possibility: a ciphersuite definition where the transmission of a follow-up fragment would be accompanied by the signature for the payload up to the restart point 🌟
3.10. Attack Model 🛡️
An evaluation of resilience to cryptographic attack depends entirely on the algorithms chosen for bulk data protection and for key transport 🔬 The mandatory ciphersuites described in the next section use AES, RSA, and SHA algorithms in ways that are believed to be reasonably secure against ciphertext-only, chosen-ciphertext, known-plaintext, and chosen-plaintext attacks 💜
The design has carefully preserved the resilience of the algorithms against attack. For example, if a message is encrypted, then any message integrity signature is also encrypted, so that guesses can't be confirmed 🔒
4. Mandatory Ciphersuites 👑
This section defines the mandatory ciphersuites for this specification. There is currently one mandatory ciphersuite for use with each of the security block types BAB, PIB, PCB, and ESB 🎀 The BAB ciphersuite is based on shared secrets using HMAC. The PIB ciphersuite is based on digital signatures using RSA with SHA-256. The PCB and ESB ciphersuites are based on using RSA for key transport and AES for bulk encryption 🔑
In all uses of CMS eContent in this specification, the relevant eContentType to be used is id-data, as specified in [RFC5652] 🧾
The ciphersuites use the mechanisms defined in Cryptographic Message Syntax (CMS) [RFC5652] for packaging the keys, signatures, and so on, for transport in the appropriate security block. The data in the CMS object is not the bundle data, which would be the typical usage for CMS. Instead, the "message data" packaged by CMS is the ephemeral key, message digest, and so on, used in the core code of the ciphersuite 🧁
In all cases where we use CMS, implementations SHOULD NOT include additional attributes, whether signed or unsigned, authenticated or unauthenticated 🙅♀️
4.1. BAB-HMAC ✨
okay so the BAB-HMAC ciphersuite has ciphersuite ID value 0x001 🎀
it uses the strict canonicalization algorithm from Section 3.4.1 💅
strict canonicalization can digest a fragment-bundle 🧩 but it won't digest just a piece of the payload. it only takes the complete contents of the payload of the current bundle, which might itself be a fragment. also, the fragment-range item in security-parameters isn't used to show a fragment, because that info is already digested inside the primary block 🦋
the variant of HMAC is HMAC-SHA1, as defined in [RFC2104] 🌸
this ciphersuite needs two related instances of the BAB, and they're both super important 👑 the first BAB instance (from Section 2.2) goes right after the primary block. the second (correlated) BAB instance MUST be placed after all the other blocks in the bundle (except possibly other BAB blocks) 🫶
so normally the BAB ends up as the second and last block in the bundle 💖 if a forwarder wants to add more than one correlated BAB pair, it can totally do that ✨ nobody has to "wrap" anyone else, but the forwarder MUST insert all the "up front" BABs and their "at back" partners (without any security-result) before canonicalizing 🍓
adding more than one pair is useful if the bundle could go to more than one possible "next hop," or if both an old key and a new key are valid at sending time and nobody knows what the situation will be at reception time 🧚
the security-result is the HMAC-SHA1 output, where the input is the whole bundle after it goes through strict canonicalization 🔥 both of the required BAB instances MUST be in the bundle before canonicalization happens 😭
security-parameters are OPTIONAL with this scheme 🌈 but if you do use them, the only field allowed is key-information (see Section 2.6) 💜
if there's no key-information, the receiver is expected to figure out the right key from the sending identity 🔍 that sending identity MAY be known from the security-source field or from the content of a previous-hop block in the bundle 🎀 it MAY also be figured out using implementation-specific stuff, like the convergence layer 🦋
4.2. PIB-RSA-SHA256 💖
the PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02 🌸
this one uses the mutable canonicalization algorithm from Section 3.4.2, and the security-result data field for only the "current" block gets left out of the canonical form 🧁 that canonical form of the bundle is what goes into the signing process ✨ it needs a single instance of the PIB 💅
here's the tea: the signature field in SignedData SignatureValue is a security-result field, so the entire key-information item MUST be placed in the block's security-result field, NOT in security-parameters 🙈
if the bundle got fragmented before it was signed, we have to say exactly which bytes were signed, just in case the signed bundle gets fragmented again later 🧩 if the bundle is a fragment, then the ciphersuite-parameters MUST include a fragment-range field (as described in Section 2.6) that says the offset and length of the signed fragment 🦋 but if the entire bundle was signed, those numbers MUST be omitted 💀
implementations MUST support the "SignedData" type from [RFC5652], Section 5.1, with the SignerInfo type SignerIdentifier holding the issuer and serial number of a suitable certificate 👑 the data to be signed is the output of the SHA256 mutable canonicalization process 🫶
RSA is used with SHA256, as specified for the id-sha256 signature scheme in [RFC4055], Section 5 ✨ the output of the signing process is the SignatureValue field for the PIB 🎀
ngl, the signing part is the bit where you really gotta be careful about what gets signed vs. what gets left out 😭
"Commensurate strength" cryptography is generally considered a really good idea 🌈 by that logic, combining RSA with SHA-256 is supposed to need a 3076-bit RSA key 🔐 few implementations will pick that length by default, and honestly some probably won't even support keys that long 💀 since this is an experimental protocol, we expect that 1024- or 2048-bit RSA keys will be used in lots of cases 🧚 and that's fine, because we also expect the hash function "issues" to get resolved before any standard comes out of this protocol 💜✨
4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB ✨
okay bestie, this ciphersuite's ID is 0x003 🎀. It encrypts the PIBs, the PCBs, AND the payload 💖. The key size is 128 bits.
Encryption uses AES in Galois/Counter Mode (GCM) as described in [RFC5084]. Heads up: some of the description is borrowed from [RFC4106] 🦋.
Why GCM? It avoids expanding the payload, and expansion causes problems with fragmentation/reassembly and custody transfer 💅. GCM also includes authentication, which is essential in preventing attacks that can alter the decrypted plaintext or even recover the encryption key 😭.
GCM is a block cipher mode of operation that gives you both confidentiality and data integrity 🔐. The GCM encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here 🧚. It has two outputs: a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the integrity check value (ICV).
For consistency with [RFC5084], we call the GCM IV a nonce. The same key and nonce combination MUST NOT be used more than once 🙈. The nonce has this layout:
+----------------+----------------+----------------+----------------+
| salt |
+----------------+----------------+----------------+----------------+
| |
| initialization vector |
| |
+----------------+----------------+----------------+----------------+
Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCBThe salt field is a four-octet value, usually chosen at random. It MUST be the same for all PCBs that have the same correlator value. The salt need not be kept secret 🧂.
The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all PCBs that have the same correlator value. The value need not be kept secret ✨.
The key (bundle encryption key, BEK) is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below 🤫.
The integrity check value is a 16-octet value used to verify that the protected data has not been altered 🛡️. It need not be kept secret.
This ciphersuite needs a single PCB instance to deal with payload confidentiality. If the bundle already contains PIBs or PCBs, the ciphersuite will create additional correlated blocks to protect them. These "additional" blocks replace the original blocks one-to-one, so the number of blocks stays the same 🔁. All of these related blocks MUST have the same correlator value. The term "first PCB" in this section refers to the single PCB if there is only one, or, if there are several, to the one containing the key-information. This MUST be the first of the set 👑.
First PCB - the first PCB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6 💅.
Security-parameterskey-informationsaltIV(this instance applies only to payload)- fragment offset and length, if bundle is a fragment
Security-resultICV
Subsequent PCBs MUST contain a correlator value to link them to the first PCB 🔗. Security-source and security-destination are implied from the first PCB; however, see the discussion in Section 2.4 concerning EID-list entries. They MUST contain security-parameters and security-result fields as follows:
Security-parametersIVfor this specific block
Security-result- encapsulated block
The security-parameters and security-result fields in the subsequent PCBs MUST NOT contain any items other than these two 🚫. Items such as key and salt are supplied in the first PCB and MUST NOT be repeated. No copy-paste, bestie 🙅♀️.
Implementations MUST support use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate 📜. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK that protects the payload and certain security blocks of the bundle 🎁.
The Integrity Check Value from the AES-GCM encryption of the payload is placed in the security-result field of the first PCB 📦.
If the bundle being encrypted is a fragment-bundle, we have to specify which bytes are encrypted in case the bundle is fragmented again later 🧩. If the bundle is a fragment, the ciphersuite-parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the encrypted fragment. Note that this is not the same pair of fields that appear in the primary block as "offset and length". The "length" in this case is the length of the fragment, not the original length. If the bundle is not a fragment, then this field MUST be omitted 🙅.
The confidentiality processing for the payload and other blocks is different, mainly because the payload might be fragmented later at some other node 👀.
For the payload, only the bytes of the bundle payload field are affected, being replaced by ciphertext. The salt, IV, and key values specified in the first PCB are used to encrypt the payload, and the resultant authentication tag (ICV) is placed in an ICV item in the security-result field of that first PCB. The other bytes of the payload block, such as type, flags, and length, are not modified. 🎀
For each PIB or PCB to be protected, the entire original block is encapsulated in a "replacing" PCB. This replacing PCB is placed in the outgoing bundle in the same position as the original block, PIB or PCB. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way 🧱.
The encryption process uses AES-GCM with the salt and key values from the first PCB, and an IV unique to this PCB. The process creates ciphertext for the entire original block and an authentication tag for validation at the security-destination. For this encapsulation process, unlike the processing of the bundle payload, the authentication tag is appended to the ciphertext for the block, and the combination is stored into the encapsulated block item in the security-result 🦋.
The replacing block, of course, also has the same correlator value as the first PCB it's associated with 💜. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in the security-result.
If the payload was fragmented after encryption, then all those fragments MUST be present and reassembled before decryption. This process might be repeated several times at different destinations if multiple fragmentation actions have occurred 🌈.
The size of the GCM counter field limits the payload size to 2^39 - 256 bytes, about half a terabyte 💀. A future revision of this specification will address the issue of handling payloads in excess of this size. Stay tuned, bestie 🫶.
4.4. ESB-RSA-AES128-EXT ✨
okay so the ESB-RSA-AES128-EXT ciphersuite is giving main character energy 💅 its ciphersuite ID value is 0x004 🎀
this scheme encrypts the non-payload-related blocks 🫶 and it MUST NOT be used to encrypt PIBs, PCBs, or primary or payload blocks 🙅♀️ the key size is 128 bits 🔐
encryption uses AES in Galois/Counter Mode (GCM), as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106] 🦋
GCM is a block cipher mode of operation that gives you both confidentiality and data origin authentication 🥹 the GCM authenticated encryption operation takes four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here 💀 it gives back two outputs: a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the Integrity Check Value (ICV) ✨
for consistency with [RFC5084], we call the GCM IV a nonce 🌸 the same key and nonce combination MUST NOT be used more than once 🚫 the nonce has the following layout:
+----------------+----------------+---------------------------------+
| salt |
+----------------+----------------+---------------------------------+
| |
| initialization vector |
| |
+----------------+----------------+---------------------------------+
Figure 7: Nonce Format for ESB-RSA-AES128-EXTthe salt field is a four-octet value, usually chosen at random 🎲 it MUST be the same for all ESBs that have the same correlator value 🔗 the salt does not need to be kept secret 🙈
the initialization vector (IV) is an eight-octet value, usually chosen at random 🍓 it MUST be different for all ESBs that have the same correlator value 💜 the IV does not need to be kept secret either 🫠
the data encryption key is a 16-octet (128 bits) value, usually chosen at random 🔑 it MUST be kept secret, as described below 🤫
the integrity check value is a 16-octet value used to verify that the protected data has not been altered 🛡️ it does not need to be kept secret 🌈
this ciphersuite replaces each BP extension block to be protected with a "replacing" ESB 🦄 and each one can be individually specified 🧚
if a bunch of related BP extension blocks need protecting, you can group them as a correlated set and protect them with a single key 👑 these blocks replace the original blocks on a one-to-one basis, so the number of blocks stays the same ✨ all of these related blocks MUST have the same correlator value 🎀 in this section, "first ESB" means the single ESB if there is only one 💖 if there are several, it means the one containing the key or key-identifier 🗝️ this MUST be the first of the set 🥇 if the blocks are individually specified, there is no correlated set, and each block is its own "first ESB" 🙌
First ESB: the first ESB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list 🌷 if those aren't specified, the bundle-source and bundle-destination get used instead, same as with other ciphersuites 💅 the block MUST contain security-parameters and security-result fields 🎀 each field MAY contain several items formatted as described in Section 2.6 🫶
the first ESB looks like this:
Security-parameters
key-information
salt
IV for this specific block
block type of encapsulated block (OPTIONAL)
Security-result
encapsulated blockSubsequent ESBs: subsequent ESBs MUST contain a correlator value to link them to the first ESB 🔗 security-source and security-destination are implied from the first ESB, but check out the discussion in Section 2.4 about EID-list entries 👀 subsequent ESBs MUST contain security-parameters and security-result fields as follows:
Security-parameters
IV for this specific block
block type of encapsulated block (OPTIONAL)
Security-result
encapsulated blockthe security-parameters and security-result fields in the subsequent ESBs MUST NOT contain any items other than those listed 🙅♀️ stuff like key-information and salt is supplied in the first ESB and MUST NOT be repeated 🚫 don't copy it over, bestie 💖
implementations MUST support the use of the "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate 🎀 they MAY support additional RecipientInfo types 🌈 the "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK used to encrypt the content of the block being protected 🔐
for each block to be protected, the entire original block gets encapsulated in a "replacing" ESB 🦋 this replacing ESB goes into the outgoing bundle in the same position as the original block 📍 like we said before, this is one-to-one replacement 😤 there is no consolidation of blocks and no mixing of data in any way 🙅♀️
the encryption process uses AES-GCM with the salt and key values from the first ESB and an IV unique to this ESB 💫 it creates ciphertext for the entire original block, plus an authentication tag for validation at the security-destination 🧚 the authentication tag gets appended to the ciphertext for the block, and the combo is stored in the encapsulated block item in security-result 🫶
the replacing block also has the same correlator value as the first ESB it's associated with 🔗 it carries the block-specific IV in security-parameters, plus the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in security-result 🥹 ✨
5. Key Management 🗝️
key management in delay-tolerant networks is recognized as a tricky topic 😭 this specification does not try to solve it 🙈 however, solely to support implementation and testing, implementations SHOULD support:
- the use of well-known RSA public keys for all ciphersuites 🔑
- long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite 🌸
endpoint IDs are URIs, and URIs can be placed in X.509 [RFC5280] public key certificates (in the subjectAltName extension) 🧾 so implementations SHOULD support this way of distributing public keys 💜 [RFC5280] does not insist that implementations include revocation checking 🤷♀️ in the context of a DTN, it's reasonably likely that some nodes wouldn't be able to use revocation checking services (either Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)) 😬 so deployments SHOULD take this into account when planning any public key infrastructure to support this specification 📋
6. Default Security Policy 🛡️
every node is a Policy Enforcement Point, because it enforces some policy that controls the forwarding and delivery of bundles via one or more convergence layer protocol implementations 👀 so every node SHALL have and operate according to its own configurable security policy, whether that policy is explicit or default 💅 the policy SHALL specify:
- under what conditions received bundles SHALL be forwarded ✨
- under what conditions received bundles SHALL be required to include valid BABs 🎀
- under what conditions the authentication information provided in a bundle's BAB SHALL be deemed adequate to authenticate the bundle 🔍
- under what conditions received bundles SHALL be required to have valid PIBs and/or PCBs 🌈
- under what conditions the authentication information provided in a bundle's PIB SHALL be deemed adequate to authenticate the bundle 🧐
- under what conditions a BAB SHALL be added to a received bundle before that bundle is forwarded 🦋
- under what conditions a PIB SHALL be added to a received bundle before that bundle is forwarded 🌷
- under what conditions a PCB SHALL be added to a received bundle before that bundle is forwarded 🍓
- under what conditions an ESB SHALL be applied to one or more blocks in a received bundle before that bundle is forwarded 🔐
- the actions that SHALL be taken if a received bundle does not meet the receiving node's security policy criteria 🚨
this specification does not address how security policies get distributed to nodes 📬 it only requires that nodes have and enforce security policies 💖
if no security policy is specified at a given node, or if a security policy is only partially specified, that node's default policy for the unspecified criteria SHALL consist of the following 🧚
- bundles that are not well-formed do not meet the security policy criteria 🙅♀️
- the mandatory ciphersuites MUST be used 🔐
- all bundles received MUST have a BAB that MUST be verified to contain a valid security-result 🛡️ if the bundle does not have a BAB, then the bundle MUST be discarded and processed no further 🗑️ a bundle status report indicating the authentication failure MAY be generated 📝
- no received bundles SHALL be required to have a PIB 🙌 if a received bundle does have a PIB, though, the PIB can be ignored unless the receiving node is the PIB-destination, in which case the PIB MUST be verified ✅
- no received bundles SHALL be required to have a PCB 🌸 if a received bundle does have a PCB, though, the PCB can be ignored unless the receiving node is the PCB-destination, in which case the PCB MUST be processed 💜 if processing a PCB yields a PIB, that PIB SHALL be processed by the node according to the node's security policy 🫶
- a PIB SHALL NOT be added to a bundle before sourcing or forwarding it 🚫
- a PCB SHALL NOT be added to a bundle before sourcing or forwarding it 🚫
- a BAB MUST always be added to a bundle before that bundle is forwarded 🎀
- if a destination node receives a bundle that has a PIB-destination but the value in that PIB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node 📦
- if a destination node receives a bundle that has an ESB-destination but the value in that ESB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node 📦
- if a received bundle does not satisfy the node's security policy for any reason, then the bundle MUST be discarded and processed no further 😤 in this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the failure MAY be generated 📝 💅
7. Security Considerations 🔐✨
Okay bestie, the Bundle Security Protocol is basically built on top of other people's amazing work 🫶. Its big foundations are "Cryptographic Message Syntax (CMS)" [RFC5652] and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], so the security considerations in those two documents apply here too. Read them, no skipping 💅.
Some other docs are also must-reads when you're building ciphersuites, especially ones that use Galois/Counter Mode (GCM) and AES 🌸. Those are "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)" [RFC4106] and "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)" [RFC5084]. BSP isn't an exact copy of those, but a lot of the same security issues still apply, so keep them in mind 👀.
Now, some DTN apps need to both sign AND encrypt a message, and that combo comes with its own drama 🎀.
If the goal is to prove that a message really came from a specific source and nobody changed it, then sign it first and encrypt it after. A signature on top of an encrypted message doesn't tie the signer to the original plaintext, so it doesn't prove that connection 🙅♀️.
BUT if the goal is to cut down on denial-of-service attacks, then signing the encrypted message is the move 💖. A message that fails the signature check never gets to the computationally intensive decryption step, so attackers can't waste your resources that way 😭.
There's a longer breakdown of all this in S/MIME 3.2 Message Specification [RFC5751], especially Section 3.6 🧠.
You'll find more details about these combos in Section 2.8, where it is RECOMMENDED that the encrypt-then-sign combination is usually appropriate for usage in a DTN 🍓. Honestly it's giving "the default you want" 💅.
In a DTN, encrypt-then-sign can let intermediate nodes verify a signature over the ciphertext. That means they can apply policy to manage storage or other resources that might be scarce, at every hop between the source EID and the destination EID 🧚.
Encrypt-then-sign also doesn't expose identity much more in most cases, because BP already requires the source EID (which is usually expected to be the security-source) to be exposed in the bundle's primary block 👑. If exposing either the source EID or the signerInfo is considered a real vulnerability, then you'd need some form of bundle-in-bundle encapsulation as a mitigation 🛡️.
Watch out: if a BAB ciphersuite uses digital signatures but doesn't include the security-destination (which for a BAB is the next host), then the bundle can be sent to some node other than the intended adjacent node 😱. The BAB will still authenticate, so the receiving node might mistakenly accept and forward the bundle. That's why, when asymmetric BAB ciphersuites are used, the security-destination field SHOULD therefore be included in the BAB 🔒.
If a bundle's PIB-destination isn't the same as its destination, then some node that isn't the final destination (the node named as the PIB-destination) is expected to validate the PIB security-result while the bundle is on its way 🚚. But if the PIB somehow never gets validated, the destination has no way of finding out 🙈. Usually a PIB-destination removes the PIB from the bundle after verifying it and before forwarding. But if there's a chance the PIB will also get verified at a downstream node, then the PIB-destination leaves the PIB in the bundle 🌈. So if a destination gets a bundle with a PIB whose PIB-destination isn't the destination, that might, but doesn't necessarily, mean something's up 👀.
Fragmentation is where things get extra spicy 🌶️. If a bundle gets fragmented after its PIB-source forwards it, but before the PIB-destination receives it, then the payload in the bundle MUST be reassembled before the PIB security-result gets validated, or the result won't validate correctly 😤. So if the PIB-destination can't do payload reassembly, it can only validate bundles that weren't fragmented since leaving the PIB-source 💅. And in that same situation, all fragments MUST be received at that PIB-destination so the payload can be put back together. If not every fragment shows up, the bundle can't be authenticated, and this PIB-destination will never forward it 💀.
Naming a security-destination that isn't the bundle-destination creates a routing requirement: the bundle has to somehow get routed to the security-destination node on its way to the final destination 🗺️. This requirement is basically private to the ciphersuite, since routing nodes aren't required to do any security processing 🫠.
Also, if a security target generated reports whenever some security validation step failed, it could leak information about the internal structure or policies of the DTN that contains the security target 🕵️♀️. That's sometimes considered bad security practice, so it SHOULD only be done with care 🫶.
8. Conformance 🎀
Like we said earlier, this document describes both BSP and ciphersuites 🌸. A conformant implementation MUST implement both BSP support and the four ciphersuites described in Section 4 💖. It MAY also support other ciphersuites too, so go wild 🦋.
Implementations that support BSP but don't have all four mandatory ciphersuites MUST claim only "restricted compliance" with this specification, even if they offer other ciphersuites 🙃. No overclaiming, bestie!
All implementations are strongly RECOMMENDED to provide at least a BAB ciphersuite 🧚. For example, a relay node might not handle end-to-end confidentiality and data integrity, but it SHOULD still exclude unauthorized traffic and do hop-by-hop bundle verification 🔥.
9. IANA Considerations 📋💅
This protocol has fields that have been registered by IANA 👑.
9.1. Bundle Block Types 🧩
This specification allocates four codepoints from the existing "Bundle Block Types" registry defined in [RFC6255] 💜.
Additional Entries for the Bundle Block-Type Codes Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 2 | Bundle Authentication Block | This document |
| 3 | Payload Integrity Block | This document |
| 4 | Payload Confidentiality Block | This document |
| 9 | Extension Security Block | This document |
+-------+--------------------------------------+----------------+9.2. Ciphersuite Numbers 🔢
This protocol has a ciphersuite number field, and certain ciphersuites are defined 🍓. An IANA registry has been set up for this, and here's how it works 👇.
The registration policy for this registry is: Specification Required
The Value range is: Variable Length
Ciphersuite Numbers Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 0 | unassigned | This document |
| 1 | BAB-HMAC | This document |
| 2 | PIB-RSA-SHA256 | This document |
| 3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB | This document |
| 4 | ESB-RSA-AES128-EXT | This document |
| >4 | Reserved | This document |
+-------+--------------------------------------+----------------+9.3. Ciphersuite Flags 🚩
This protocol has a ciphersuite flags field, and certain flags are defined ✨. An IANA registry has been set up as follows 💅.
The registration policy for this registry is: Specification Required
The Value range is: Variable Length
Ciphersuite Flags Registry:
+-----------------+----------------------------+----------------+
| Bit Position | Description | Reference |
| (right to left) | | |
+-----------------+----------------------------+----------------+
| 0 | Block contains result | This document |
| 1 | Block contains correlator | This document |
| 2 | Block contains parameters | This document |
| 3 | Destination EIDref present | This document |
| 4 | Source EIDref present | This document |
| >4 | Reserved | This document |
+-----------------+----------------------------+----------------+9.4. Parameters and Results 🎁
This protocol has fields for ciphersuite-parameters and results 🫧. The field is a type-length-value triple, and a registry is required for the "type" sub-field 💜. The values for "type" apply to both the ciphersuite-parameters and the ciphersuite results fields 🌈. Certain values are defined, and an IANA registry has been set up as follows 🦋.
The registration policy for this registry is: Specification Required
The Value range is: 8-bit unsigned integer
Ciphersuite-Parameters and Results Type Registry:
+---------+------------------------------------+----------------+
| Value | Description | Reference |
+---------+------------------------------------+----------------+
| 0 | reserved | This document |
| 1 | initialization vector (IV) | This document |
| 2 | reserved | This document |
| 3 | key-information | This document |
| 4 | fragment-range (pair of SDNVs) | This document |
| 5 | integrity signature | This document |
| 6 | unassigned | This document |
| 7 | salt | This document |
| 8 | PCB integrity check value (ICV) | This document |
| 9 | reserved | This document |
| 10 | encapsulated block | This document |
| 11 | block type of encapsulated block | This document |
| 12-191 | reserved | This document |
| 192-250 | private use | This document |
| 251-255 | reserved | This document |
+-------+--------------------------------------+----------------+10. References 📚
10.1. Normative References 📚✨
okay so these are the normative refs, aka the docs you literally NEED to read before this spec makes any sense 💅
[DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[DTNMD] Symington, S., "Delay-Tolerant Networking Metadata
Extension Block", RFC 6258, May 2011.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle
Protocol IANA Registries", RFC 6255, May 2011.10.2. Informative References 🦋
these ones are the extra reading 🧚 handy for the full picture, but you don't have to read them to follow the spec
[DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[PHIB] Symington, S., "Delay-Tolerant Networking Previous-Hop
Insertion Block", RFC 6259, May 2011.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, November 2007.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.Authors' Addresses 💖
the squad behind this spec, the people to thank (or DM) 🫶
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
EMail: susan@mitre.org
URI: http://mitre.org/
Stephen Farrell
Trinity College Dublin
Distributed Systems Group
Department of Computer Science
Trinity College
Dublin 2
Ireland
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Howard Weiss
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
US
Phone: +1-443-430-8089
EMail: howard.weiss@sparta.com
Peter Lovell
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
US
Phone: +1-443-430-8052
EMail: dtnbsp@gmail.com📦 where this page comes from
- ietf: rfc6257 2011-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms