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]