tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6257


Bundle Security Protocol Specification

Part 2 of 3, p. 25 to 42
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 25 
3.  Security Processing

   This section describes the security aspects of bundle processing.

Top      Up      ToC       Page 26 
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.

Top      Up      ToC       Page 27 
   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

Top      Up      ToC       Page 28 
   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
   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

Top      Up      ToC       Page 29 
   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
   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").

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
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

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   |    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.

Top      Up      ToC       Page 35 
      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

   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.

Top      Up      ToC       Page 36 
   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

Top      Up      ToC       Page 37 
      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.

Top      Up      ToC       Page 38 
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

Top      Up      ToC       Page 39 
   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

   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

Top      Up      ToC       Page 40 
   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].

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
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)

Next RFC Part