The DTN Bundle Protocol Payload Checksum Block

Reliable transmission of information is a well-known problem for all protocol layers. Error detection and correction capabilities are found in lower layers, but are also present in many higher-layer protocols in order to detect residual bit errors and bugs. For example, IPv4 verifies a simple header checksum before processing inbound packets, even when running over a data link like Ethernet that already performs a stronger CRC, and TCP and UDP segments further includes a checksum covering their contents as well as some IP header fields. What may seem like paranoia is actually not unfounded, as errors in received data or packet corruption are known to creep into packets from causes other than channel noise . Although coding of data on the channel can reduce the impact of channel noise, end-to-end checksums are understood to be necessary for applications requiring relative certainty that the data received is error-free . The Delay/Disruption-Tolerant Networking (DTN) architecture is founded on an overlay of Bundle Agents (BAs), that forward data units called bundles via a Bundle Protocol . Bundles may be lost or errored both during transmission between BAs, or within a BA itself. Bundles belonging to applications that are not tolerant of lost data have a "custody transfer" flag that requests reliable transmission between bundle agents. Unfortunately, the notion of reliability used in the basic custody transfer mechanism does not take bit errors into account. It is assumed that the "convergence layer adapters" that connect BAs to each other will detect and correct errors before presenting bundle data to the BAs themselves. This may be adequate in many cases, but is not always sufficient, and the insufficiency is encapsulated in the well-known end-to-end principle . It is possible (and even statistically likely) that either transmission errors will go unnoticed, or unchecked errors will be introduced within a BA's memory, storage, or forwarding systems. For example, the UDP convergence-layer adapter that has been popularly implemented in DTN stacks uses the usual IP 16-bit one's-complement checksum to validate incoming packets. This checksum is computed by summing 16-bit values within a packet. If two strings within the packet of size greater than 16 bits are swapped in position, the checksum will pass even though the datagram is now different from the original, and clearly errored. The proposed TCP-based convergence layer relies on the same checksum algorithm. This checksum algorithm is considered weak, in that it does not detect a class of subtle errors, but at least an attempt to verify that the packet was as sent has been made. Even stronger convergence-layer adapter error detection is not sufficient. Errors within a BA's memory, errors due to memory issues within the BA's host, e.g. radiation-induced soft errors, or errors introduced from file-system corruption cannot be detected by convergence layer adapters, as these errors occur in between successive phases of forwarding and convergence-layer processing. End-to-end computation and verification of checksums is required to ensure integrity of DTN bundles forwarded across a system composed of BAs and convergence layer adapters . The proposed Bundle Security mechanisms are capable of providing an end-to-end checksum, but are intended for the very different problem of security. The current design of Bundle Security is not practical for simple integrity checking outside of a more paranoid security context. For example, the Bundle Security mechanisms include "mandatory ciphersuites" that implementations must support. No simple checksum algorithm is among the mandated algorithms. The mandated ciphersuites do include some more complex keyed-hash constructions, but these rely on key management, which is not appropriate for general integrity checking between multiple parties simply relaying bundles. While it would be technically possible to graft a non-security integrity-checking mechanism onto the avaiable security mechanisms by specifying some assumed key, it would be inapproriate for the problem at hand, and overkill. Instead, it would be much simpler and less error-prone to implement a separate checksum block for optional inclusion on bundles. of this document defines such a block and gives some simple rules for its use.

A new bundle block, the Payload Checksum Block, is defined in this section, for inclusion in bundles where integrity checking is desirable. An un-keyed checksum algorithm is used. The integrity verification that it provides covers only the bundle payload, as several portions of other bundle blocks are allowed (and expected) to change in-transit as a bundle is forwarded through a DTN. The implications of this decision are discussed in the next section. No Endpoint ID references are needed for this, so the layout follows that of Figure 6 in the Bundle Protocol specification , with its use of Self-Delimiting Numeric Values (SDNVs):

+-----------+-----------+-----------+-----------+ |Block Type | Block Processing Ctrl Flags (SDNV)| +-----------+-----------+-----------+-----------+ | Block Length (SDNV) | +-----------+-----------+-----------+-----------+ | Checksum Algorithm (SDNV) | +-----------+-----------+-----------+-----------+ | | | Payload Checksum Value | | (variable length) | | | +-----------------------------------------------+ The fields shown in above are defined as: Block Type - Implementations are currently using a value defined as experimental in the Bundle Protocol Specification, but can be expected to transition to an assigned value. Block Processing Ctrl Flags - The bits in this SDNV are defined in the Bundle Protocol Specification. For Payload Checksum Blocks, none of these bits need be set, except perhaps bit 3, to indicate the "last block", when the block is sent as the final block in a bundle. Block Length - This SDNV encodes the length of the remainder of the Payload Checksum Block. When the Checksum Algorithm SDNV is parsed, its length can be subtracted from the Block Length value to determine the level of truncation for the Payload Checksum Value, as explained below. Checksum Algorithm - This identifies the algorithm used to compute the Payload Checksum Value field following it. Defined algorithms are listed below. Payload Checksum Value - This is a raw string of octets whose length is implied by the Block Length. This string contains the checksum result computed over the Payload Block of the bundle, and may only contain the high-order bits of this result, if truncation is used to shorten the length of the checksum, as described below.

Any implementation of this specification MUST support the MD5 checksum algorithm . MD5 has been chosen as the baseline checksum algorithm in this mechanism because it represents a reasonable tradeoff between robust error detection and efficiency of implementation. For widespread use in DTNs, both resource-efficient implementation and decent error-detection capabilities are needed. MD5 algorithms are known to achieve processing several Mbps, even on rather limited hardware , yet MD5 provides a much more robust checksum than the Internet's 16-bit one's complement checksum. Although MD5 has cryptographic weaknesses and is discouraged for use in security protocols, concerns with resistance to pre-image generation are irrelevant here as we are not using MD5 values in a security context. We also have a defined value to indicate use of SHA-1 checksums . However, support for SHA-1 checksums is not required. SHA-1 is significantly less efficient than MD5 to compute in our experience, for seemingly little added error-detection capability when truncated to the same length. Implementations SHOULD at least support receiving and verifying SHA-1 checksums. An Adler-32 checksum option is also specified, but should be used only in cases where bundle payloads are relatively small and efficiency of computation is highly important. Implementations SHOULD support at least receiving and verifying Adler-32 checksums. The complete list of currently defined Checksum Algorithm values is: #AlgorithmUn-Truncated Length 0MD5128 bits 1SHA-1160 bits 2Adler-3232 bits Other checksum algorithms may be assigned values in future documents.

On small payloads, the relatively long output of the MD5 or SHA-1 algorithms might be viewed as a detriment to end-to-end application performance by increasing the header overhead of the Bundle Protocol, and reducing the capacity available to higher layers. For this reason, senders of the Payload Checksum Block are permitted to truncate the transmitted Payload Checksum Values if the full checksum algorithm's output is deemed to be overly long in comparison to the size of the payload. This should be done carefully at the sending application's discretion, and never by default. When generating or verifying a truncated checksum, it is understood that only the high-order octets are included. The checksum conveyed in the Payload Checksum Block only covers the Payload Block of a bundle, and does not include any pseudoheaders with EIDs, timestamps, etc., or any other portion of a bundle or its other extension blocks. Ensuring robustness of bundle header information and metadata is a separate problem not addressed here; ideally each header would be self-checking to guarantee a degree of robustness on receipt. The checksum within the Payload Checksum Block has differing semantics if it occurs before or after the Payload Block. If placed before the Payload Block, then the Checksum Value should be understood to cover the entire (unfragmented / reassembled) payload, whereas if it follows the Payload Block within a Bundle Fragment, then the Checksum Value only applies to the included fragment of the payload. Intermediate Bundle Agents, which may not be affiliated with either the source nor the destination of a bundle, are permitted to verify the Payload Checksum Block and attempt local recovery. If local recovery is not possible, then the bundle MAY be deleted. This document suggests amending the Bundle Protocol specification with regard to Custody Transfer. Without any checksum verification, claiming custody of a bundle is a potentially troublesome operation. We suggest that the Bundle Protocol specification require the use of a Payload Checksum Block when Custody Transfer is requested by an application in order to close this gap.

The mechanism described in this document does not introduce any new security concerns beyond those present in the basic Bundle Protocol. It only attempts to ensure the reliability of the Bundle Protocol payload. Ensuring Bundle Protocol header reliability remains an open problem.

This document has no considerations for IANA.

Some of the work on this document was performed at NASA's Glenn Research Center under funding from the Earth Science Technology Office (ESTO) and the Space Communications Architecture Working Group (SCAWG).