Internet DRAFT - draft-templin-dtnhiaps
draft-templin-dtnhiaps
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational March 12, 2014
Expires: September 13, 2014
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
Templin Expires September 13, 2014 [Page 1]
Internet-Draft DTNHIAPS March 2014
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Templin Expires September 13, 2014 [Page 2]
Internet-Draft DTNHIAPS March 2014
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.
Templin Expires September 13, 2014 [Page 3]
Internet-Draft DTNHIAPS March 2014
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
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
Templin Expires September 13, 2014 [Page 4]
Internet-Draft DTNHIAPS March 2014
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
6.2. Informative References
[I-D.irtf-dtnrg-sbsp]
Birrane, E., "Streamlined Bundle Security Protocol
Specification", draft-irtf-dtnrg-sbsp-00 (work in
progress), July 2013.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
May 2011.
[WOOD08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of
Problems", December 2008.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires September 13, 2014 [Page 5]
