3.1. Nodes as Policy Enforcement Points
All nodes are REQUIRED to have and enforce their own configurable
security policies, whether these policies be explicit or default, as
defined in Section 6.
All nodes serve as Policy Enforcement Points (PEPs) insofar as they
enforce polices 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
The processing order of security actions for a bundle is critically
important for the actions to complete successfully. In general, the
actions performed at the originating node MUST be executed in the
reverse sequence at the destination. There are variations and
exceptions, and these are noted below.
The sequence is maintained in the ordering of security blocks in the
bundle. It is for this reason that blocks MUST NOT be rearranged at
forwarding nodes, whether or not they support the security protocols.
The only blocks that participate in this ordering are the primary and
payload blocks, and the PIB and PCB security blocks themselves. All
other extension blocks, including ESBs, are ignored for purposes of
determining the processing order.
The security blocks are added to and removed from a bundle in a last-
in-first-out (LIFO) manner, with the top of the stack immediately
after the primary block. A newly created bundle has just the primary
and payload blocks, and the stack is empty. As security actions are
requested for the bundle, security blocks are pushed onto the stack
immediately after the primary block. The early actions have security
blocks close to the payload, later actions have blocks nearer to the
primary block. The actions deal with only those blocks in the bundle
at the time, so, for example, the first to be added processes only
the payload and primary blocks, the next might process the first if
it chooses and the payload and primary, and so on. The last block to
be added can process all the blocks.
When the bundle is received, this process is reversed and security
processing begins at the top of the stack, immediately after the
primary block. The security actions are performed, and the block is
popped from the stack. Processing continues with the next security
block until finally only the payload and primary blocks remain.
The simplicity of this description is undermined by various real-
world requirements. Nonetheless, it serves as a helpful initial
framework for understanding the bundle security process.
The first issue is a very common one and easy to handle. The bundle
may be sent indirectly to its destination, requiring several
forwarding hops to finally arrive there. Security processing happens
at each node, assuming that the node supports bundle security. For
the following discussion, we assume that a bundle is created and that
confidentiality, then payload integrity, and finally bundle
authentication are applied to it. The block sequence would therefore
be primary-BAB-PIB-PCB-payload. Traveling from source to destination
requires going through one intermediate node, so the trip consists of
When the bundle is received at the intermediate node, the 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 these cannot be processed and removed. The
intermediate node then begins the send process with the four
remaining blocks in the bundle. The outbound processing adds any
security blocks required by local policy, and these are pushed on the
stack immediately 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.
The receive processing at the destination first handles the
intermediate node's PIB and pops it, next is the originator's PIB,
also popped, and finally the originator's confidentiality block that
allows the payload to be decrypted and the bundle handled for
In practice, DTNs are likely to be more complex. The security policy
for a node specifies the security requirements for a bundle. The
policy will possibly cause one or more security operations to be
applied to the bundle at the current node, each with its own
security-destination. Application of 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. This is discussed further in Section 3.3.
The second issue relates to the 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, does not
change the bundle content except for the result. The encryption
performed as part of the confidentiality processing does change the
bundle, but the reverse processing at the destination restores the
The third category is the one where the bundle content has changed
slightly and in a non-destructive way, but there is no mechanism to
reverse the change. The simplest example is the addition of an EID-
reference to a security block. The addition of the reference causes
the text to be added to the bundle's dictionary. The text may also
be used by other references, so removal of the block and this
specific EID-reference does not cause removal of the text from the
dictionary. This shortcoming is of no impact to the "sequential" or
"wrapping" security schemes described above, but does cause failures
with "parallel" authentication mechanisms. Solutions for this
problem are implementation specific and typically involve multi-pass
processing such that blocks are added at one stage and the security-
results 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 prior to any receive operations at the
next-hop node. Therefore, it follows that BABs MUST always be pushed
onto the stack after all others.
Although we describe the security block list as a stack, there are
some blocks that are placed after the payload and therefore are not
part of the stack. The BundleAuthentication ciphersuite #1 ("BA1")
requires a second, correlated block to contain the security-result,
and this block is placed after the payload, usually as the last block
in the bundle. We can apply the stack rules even 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
ESBs are effectively placeholders for the blocks they encapsulate
and, since those do not form part of the processing sequence
described above, ESBs themselves do not either. ESBs MAY be
correlated, however, so the "no reordering" requirement applies to
them as well.
3.3. Security Regions
Each security block has a security path, as described in the
discussion for Figure 1, and the paths for various blocks are often
BABs are always for a single hop, and these restricted paths never
The paths for PIBs and PCBs are often from bundle-source to bundle-
destination, to provide end-to-end protection. A bundle-source-to-
bundle-destination path likewise never causes a problem.
Another common scenario is for gateway-to-gateway protection of
traffic between two sub-networks ("tunnel-mode").
Looking at Figure 1 and the simplified version shown in Figure 4, we
can regard 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. Problems begin, for example, when BN2 adds
blocks with BN4 as the security-destination, and the originating node
BN1 has created blocks with BN3 as security-destination. We now have
two paths, and neither is a subset of the other.
This scenario should be prevented by node BN2's security policy being
aware of the already existing block with BN3 as the security-
destination. This policy SHOULD NOT specify a security-destination
that is further distant than any existing security-destination.
+---------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 Paths
Consider the case where the security concern is for 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
primary - PIb - PIa - payload
Block PIb is not destined for this node BN3, so it has to be
forwarded. This 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.
The situation would be worse 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 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 use care to
ensure that their policies do not 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
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
In order 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 upon initial computation of the original
signature or MAC value. Consequently, a node MUST NOT change the
encoding of any URI [RFC3986] in the dictionary field, e.g., changing
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 bundle canonicalization algorithms used in
Sections 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 that can be used permits no changes at all to the
bundle between the security-source and the security-destination. It
is 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.
That is, 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 included, even though their corresponding security-result data
fields are omitted.
o 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. Rather, 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
o The 'res' bit 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.
o 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.
o 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
This algorithm is intended to protect parts of the bundle that SHOULD
NOT be changed in transit. Hence, it omits the mutable parts of the
The basic approach is to define a canonical form of the primary block
and catenate it with the security (PIBs and PCBs only) and payload
blocks in the order that they will be transmitted. This algorithm
ignores all other blocks, including ESBs, because it cannot be
determined whether or not they will change as the bundle transits the
network. In short, this canonicalization protects the payload,
payload-related security blocks, and parts of the primary block.
Many fields in various blocks are stored as variable-length SDNVs.
These are canonicalized in unpacked form, as eight-byte fixed-width
fields in network byte order. The size of eight bytes is chosen
because implementations MAY handle larger values as invalid, as noted
The canonical form of the primary block is shown in Figure 5.
Essentially, it de-references the dictionary block, adjusts lengths
where necessary, 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 Block
The fields shown in Figure 5 are as follows:
The version value is the single-byte value in the primary block.
The processing flags value in the primary block is an SDNV, and
includes the class-of-service (COS) and status report request
(SRR) fields. For purposes of canonicalization, the SDNV is
unpacked into a fixed-width field, and some bits are masked out.
The unpacked field is ANDed with mask 0x0000 0000 0007 C1BE to set
to zero all reserved bits and the "bundle is a fragment" bit.
The canonical primary block length value is a four-byte value
containing the length (in bytes) of this structure, in network
The destination endpoint ID length and value are the length (as a
four-byte value in network byte order) and value of the
destination endpoint ID from the primary bundle block. The URI is
simply copied from the relevant part(s) of the dictionary block
and is not itself canonicalized. Although the dictionary entries
contain "null-terminators", the null-terminators are not included
in the length or the canonicalization.
The source endpoint ID length and value are handled similarly to
The report-to endpoint ID length and value are handled similarly
to the destination.
The creation timestamp (2 x SDNV) and lifetime (SDNV) are simply
copied from the primary block, with the SDNV values being
represented as eight-byte unpacked values.
Fragment offset and total application data unit length are
ignored, as is the case for the "bundle is a fragment" bit
mentioned above. If the payload data to be canonicalized is less
than the complete, original bundle payload, the offset and length
are specified in the security-parameters.
For non-primary blocks being included in the canonicalization, the
block processing control flags value used for canonicalization is the
unpacked SDNV value with reserved and mutable bits masked to zero.
The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero
reserved bits and the "last block" flag. The "last block" flag is
ignored because BABs and other security blocks MAY be added for some
parts of the journey but not others, so the setting of this bit might
change from hop to hop.
Endpoint ID references in security blocks are canonicalized using the
de-referenced text form in place of the reference pair. The
reference count is not included, nor is the length of the endpoint ID
The block-length is canonicalized as an eight-byte unpacked value in
network byte order. If the payload data to be canonicalized is less
than the complete, original bundle payload, this field contains the
size of the data being canonicalized (the "effective block") rather
that the actual size of the block.
Payload blocks are generally canonicalized as-is, with the exception
that, in some instances, only a portion of the payload data is to be
protected. In such a case, only those bytes are included in the
canonical form, and additional ciphersuite-parameters are required to
specify which part of the payload is protected, as discussed further
Security blocks are handled likewise, except that the ciphersuite
will likely specify that the "current" security block security-result
field not be considered part of the canonical form. This differs
from the strict canonicalization case since we might use the mutable
canonicalization algorithm to handle sequential signatures such that
signatures cover earlier ones.
ESBs MUST NOT be included in the canonicalization.
o The canonical form of the bundle is not transmitted. It is simply
an artifact used as input to digesting.
o We omit the reserved flags because we cannot determine if they
will change in transit. The masks specified above will have to be
revised if additional flags are defined and they need to be
o Our URI encoding does not preserve the null-termination convention
from the dictionary field, nor do we separate the scheme and the
scheme-specific part (SSP) as is done there.
o The URI encoding will cause errors if any node rewrites the
dictionary content (e.g., changing the DNS part of an HTTP URL
from lower case to upper case). This could happen transparently
when a bundle is synched to disk using one set of software and
then read from disk and forwarded by a second set of software.
Because there are no general rules for canonicalizing URIs (or
IRIs), this problem may be an unavoidable source of integrity
o 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 does not need
optimization since the values are never sent over the network.
If a bundle is fragmented before the PIB is applied, then the PIB
applies to a fragment and not the entire bundle. However, the
protected fragment could be subsequently further fragmented, which
would leave the verifier unable to know which bytes were protected
by the PIB. Even in the absence of fragmentation, the same
situation applies if the ciphersuite is defined to allow
protection of less than the entire, original bundle payload.
For this reason, PIB ciphersuites that support applying a PIB to
less than the complete, original bundle payload MUST specify, as
part of the ciphersuite-parameters, which bytes of the bundle
payload are protected. When verification occurs, only the
specified range of the payload bytes are input to PIB
verification. It is valid for a ciphersuite to be specified so as
to only apply to entire bundles and not to fragments. A
ciphersuite MAY be specified to apply to only a portion of the
payload, regardless of whether the payload is a fragment or the
complete, original bundle payload.
The same fragmentation issue applies equally to PCB ciphersuites.
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 are processed. It is also valid for a
confidentiality ciphersuite to be specified so as to only apply to
entire bundles and not to fragments.
This definition of mutable canonicalization assumes that endpoint IDs
themselves are immutable and is unsuitable for use in environments
where that assumption might be violated.
The canonicalization applies to a specific bundle and not a specific
payload. If a bundle is forwarded in some way, the recipient is not
able to verify the original integrity signature since the source EID
will be different, and possibly other fields.
The solution for either of these issues is to define and use a PIB
ciphersuite having 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 contains the source
and destination endpoint IDs, and possibly other EIDs (in the
dictionary field), and that cannot be encrypted. If endpoint ID
confidentiality is required, then bundle-in-bundle encapsulation can
solve this problem in some instances.
Similarly, confidentiality requirements MAY also apply to other parts
of the primary block (e.g., the current-custodian), and that is
supported in the same manner.
3.6. Bundles Received from Other Nodes
Nodes implementing this specification SHALL consult their security
policy to determine whether or not a received bundle is required by
policy to include a BAB. If the bundle has no BAB, and one is not
required, then BAB processing on the received bundle is complete, and
the bundle is ready to be further processed for PIB/PCB/ESB handling
or delivery or forwarding.
If the bundle is required to have a BAB but does not, then the bundle
MUST be discarded and processed no further. If the bundle is
required to have a BAB but all of its BABs identify a node other than
the receiving node as the BAB security-destination, then the bundle
MUST be discarded and processed no further.
If the bundle is required to have a BAB, and has one or more BABs
that identify the receiving node as the BAB security-destination, or
for which there is no security-destination, then the value in the
security-result field(s) of the BAB(s) MUST be verified according to
the ciphersuite specification. If, for all such BABs in the bundle,
either the BAB security source cannot be determined or the security-
result value check fails, the bundle has failed to authenticate, and
the bundle MUST be discarded and processed no further. If any of the
BABs present verify, or if a BAB is not required, the bundle is ready
for further processing as determined by extension blocks and/or
BABs received in a bundle MUST be stripped before the bundle is
forwarded. New BABs MAY be added as required by policy. This MAY
require correcting the "last block" field of the to-be-forwarded
Further processing of the bundle MUST take place in the order
indicated by the various blocks from the primary block to the payload
block, except as defined by an applicable specification.
If the bundle has a PCB and the receiving node is the PCB-destination
for the bundle (either because the node is listed as the bundle's
PCB-destination or because the node is listed as the bundle-
destination and there is no PCB-dest), the node MUST decrypt the
relevant parts of the bundle in accordance with the ciphersuite
specification. The PCB SHALL be deleted. If the relevant parts of
the bundle cannot be decrypted (i.e., the decryption key cannot be
deduced or decryption fails), 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
decryption failure MAY be generated. 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 from which the PCB was deleted.
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 the node is listed as the
bundle-destination and there is no PIB-dest), the node MUST verify
the value in the PIB security-result field(s) in accordance with 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 either 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 is
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 is able to check and the check fails,
the node SHALL discard the bundle and it MAY send a bundle status
report indicating the failure.
If the bundle has an ESB and the receiving node is the ESB-
destination for the bundle (either because the node is listed as the
bundle's ESB-destination or because the node is listed as the bundle-
destination and there is no ESB-destination), the node MUST decrypt
and/or decapsulate the encapsulated block in accordance with the
ciphersuite specification. The decapsulated block replaces the ESB
in the bundle block sequence, and the ESB is thereby deleted. If the
content cannot be decrypted (i.e., the decryption key cannot be
deduced or decryption fails), then the bundle MAY be discarded and
processed no further unless the security policy specifies otherwise.
In this case, a bundle deletion status report (see the Bundle
Protocol Specification [DTNBP]) indicating the decryption failure MAY
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
An option for use in such cases is known as "at-most-once-delivery".
If this option is chosen, the application indicates that 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 this
option is not chosen, the application indicates that it wants the
node to deliver all received bundle copies to the application. If
this option is chosen, the node SHALL deliver at most one copy of
each received bundle to the application. If the option is not
chosen, the node SHOULD, subject to policy, deliver all bundles.
To enforce this, the node MUST look at the source/timestamp pair
value of each complete (reassembled, if necessary) bundle received
and determine if this pair, which uniquely identifies a bundle, has
been previously received. If it has, then the bundle is a duplicate.
If it has not, then 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 maintain a table of
pair value state.
3.8. Bundle Fragmentation and Reassembly
If it is necessary for a node 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. In
addition, the following security-specific processing is REQUIRED:
The security policy requirements for a bundle MUST be applied
individually to all the bundles resulting 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, and thereby be replicated in every
fragment. This is to ensure that the canonical block-sequence can be
recovered during reassembly.
If the original bundle contained one or more correlated PCBs not
containing a key-information item, then each of these MUST be
included in some fragment, but SHOULD NOT be sent more than once.
They MUST be placed in a fragment in accordance with the
fragmentation rules described in [DTNBP].
Note: various fragments MAY have additional security blocks added at
this or later stages, and it is possible that correlators will
collide. In order to facilitate uniqueness, 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 determine if it MAY fragment the
bundle, converting the received portion into a bundle fragment for
further forwarding. Whether or not reactive fragmentation is
permitted SHALL depend on the security policy and the ciphersuite
used to calculate the BAB authentication information, if required.
(Some BAB ciphersuites, i.e., the mandatory BAB-HMAC (Hashed Message
Authentication Code) ciphersuite defined in Section 4.1, do not
accommodate reactive fragmentation because the security-result in the
BAB requires that the entire bundle be signed. It is conceivable,
however, that a BAB ciphersuite could be defined such that multiple
security-results are calculated, each on a different segment of a
bundle, and that these security-results could be interspersed between
bundle payload segments such that reactive fragmentation could be
If the bundle is reactively fragmented by the intermediate receiver
and the BAB-ciphersuite is of an appropriate type (e.g., 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 is 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
This specification does not define any ciphersuite that can handle
this reactive fragmentation case.
An interesting possibility is a ciphersuite definition such that 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 necessarily
depends upon the algorithms chosen for bulk data protection and for
key transport. The mandatory ciphersuites described in the following
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 cannot