RFC 6257
Bundle Security Protocol Specification
3. Security Processing
This section describes the security aspects 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 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 two hops. 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 delivery. 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 original content. 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
so.
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
different.
BABs are always for a single hop, and these restricted paths never
cause conflict.
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 are 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
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
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. Notes: 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 omitted. 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 bundle.
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 in [DTNBP]. 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 byte order.
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 destination.
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
text.
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
below.
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.
Notes:
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
protected.
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
failures.
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 policy. 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 bundle. 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 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. 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 accommodated.) 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 recalculated. 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 be confirmed.
(page 42 continued on part 3)
