Delay Tolerant Networking Header Integrity Assurance - Problem Statement
draft-templin-dtnhiaps-00.txt

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 13, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Discussion
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

The Delay/Disruption Tolerant Network (DTN) architecture [RFC4838] 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 [RFC5050] 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) [RFC6257] and/or Streamlined Bundle Security Protocol (SBSP) [I-D.irtf-dtnrg-sbsp] specifications.

[WOOD08], 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, [WOOD08] 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.

2. Discussion

Internet Protocol, version 4 (IPv4) [RFC0791] 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) [RFC2460] 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.

3. IANA Considerations

There are no IANA considerations for this document.

4. Security Considerations

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 [RFC6257][I-D.irtf-dtnrg-sbsp].

5. Acknowledgments

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

6. References

6.1. Normative References

6.2. Informative References

Author's Address