Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft Delay/Disruption Tolerant Networking (DTN) introduces a network model for environments in which communications may be subject to long delays and/or intermittent connectivity. A Bundle Protocol (BP) has been designed to accommodate data communications in such challenging environments through multi-hop store-and-forward message propagation, where each hop may be required to store bundles of data for long periods of time. It is therefore essential that bundles with corrupted headers (e.g., the primary bundle block) be detected as soon as possible in order to avoid resource exhaustion due to accidental or malicious factors, and to permit timely retransmission. In this document, we discuss the need for a hop-by-hop integrity assurance as a means for encouraging suitable solutions.

The Delay/Disruption Tolerant Network (DTN) architecture introduces a data communications concept in which "bundles" of data are exchanged in store-and-forward fashion between endpoints that may be separated by long-delay or intermittently-connected paths. The Bundle Protocol (BP) Specification provides the bundle message format and operations, including convergence layer transmission, fragmentation and custody transfer. Each bundle further may include extensions, among which may be security parameters designed to ensure confidentiality, integrity and authorization per the Bundle Security Protocol (BSP) and/or Streamlined Bundle Security Protocol (SBSP) specifications. , Section 4.1 has shown that including integrity checks only between the original source and final destination can lead to poor performance when primary bundle blocks are corrupted on intermediate hops on the path (where the source of corruption may be accidental or through the malicious acts of an attacker). Conversely, establishes that adding a hop-by-hop integrity check can provide a tighter control loop resulting in faster retransmissions and more timely delivery of bundles to the final destination. In the following section, we discuss the problem as a means for encouraging solution proposals.

Internet Protocol, version 4 (IPv4) includes a checksum in the header of each packet as a weak assurance against mis-delivery or corruption of critical protocol control fields. The checksum is verified then recalculated at each hop along the path from source to destination, and the packet is discarded at any hop where the checksum is incorrect. Internet Protocol, version 6 (IPv6) does not include a header checksum, but requires upper layer protocols (TCP, UDP, etc,) to include a "pseudo-header" of the IPv6 header when calculating their checksum values. This means that an IPv6 packet with header corruption may traverse many networking hops and may even arrive at the final destination before the corruption is detected. The DTN protocols currently adhere to the example established by IPv6, but differ in the sense that for a transport layer connection spanning a single Internet the end-to-end delay is typically only a few tens to a few hundreds of milliseconds where for a DTN path connecting multiple Internets the delay may be substantially longer. Since the continued store-and-forward progression of corrupted primary bundle block information needlessly consumes resources, and since the DTN protocols are typically associated with resource-constrained environments, it is critical that some form of hop-by-hop integrity solution be incorporated. This could come in the form of a security protocol integrity block signed with a key that is known to all DTN nodes. At a minimum, the integrity check should cover the primary bundle block but may or may not be applied to the payload since in some cases delivery of partially-corrupted data is deemed acceptable and better than getting no data at all. Therefore, a hop-by-hop integrity capability should be included in the DTN security protocols and applied as a matter of course in many DTN environments. However, it is worth examining each DTN use case individually to determine where an integrity check is necessary vs where the check can be avoided. This document does not suggest an approach to address the issue, but rather outlines the problems and invites solution proposals.

There are no IANA considerations for this document.

Message integrity is an integral aspect of security, since corruption may occur either as an accident or through the purposeful actions of an adversary. DTN security considerations are discussed in .

Integrity issues have been discussed broadly in DTN mailing list discussions as well as in many of the documents cited in this publication.