[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
Network Working Group                                            W. Eddy
Internet-Draft                                                   Verizon
Intended status: Experimental                                    L. Wood
Expires: August 28, 2008                                   Cisco Systems
                                                              W. Ivancic
                                                                    NASA
                                                       February 25, 2008


             Checksum Ciphersuites for the Bundle Protocol
                  draft-irtf-dtnrg-bundle-checksum-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The Delay-Tolerant Networking Bundle Protocol includes a custody
   transfer mechanism to provide acknowledgements of receipt for
   particular bundles.  No checksum is included in the basic DTN Bundle
   Protocol, however, so it is not possible to verify that bundles have
   been either forwarded or passed through various convergence layers



Eddy, et al.             Expires August 28, 2008                [Page 1]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   without errors having been introduced.  Without assurance that a
   bundle has been received without errors, the custody transfer receipt
   cannot guarantee that a correct copy of the bundle has been
   transferred.  This document attempts to address the situation by
   defining new ciphersuites for use within the existing Bundle Security
   Protocol's Payload Integrity Block (formerly called the Payload
   Security Block) to provide error-detection functions regardless of an
   implementation's support for other, more complex, security-providing
   ciphersuites.  This creates the checksum service needed for error-
   free reliability, but does so at the expense of divorcing security
   concerns from the few new reliability-only ciphersuite definitions
   that are introduced here.  This document lengthily discusses the pros
   and cons of this approach and the existing constraints that combined
   to drive this design.


Table of Contents

   1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview of Header and Payload Integrity . . . . . . . . .  4
   2.  Use of the Payload Integrity Block . . . . . . . . . . . . . .  6
     2.1.  Differences from Intended Use of the Payload Integrity
           Block  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  INSECURE Ciphersuites  . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Generation and Processing Rules  . . . . . . . . . . . . . 12
   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Mandatory BSP Elements Needed to Implement
                Error-Detection . . . . . . . . . . . . . . . . . . . 18
     A.1.  Mutable Canonicalization . . . . . . . . . . . . . . . . . 18
     A.2.  PIB Format . . . . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22













Eddy, et al.             Expires August 28, 2008                [Page 2]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


1.  Motivations

   Reliable transmission of information is a well-known problem for all
   protocol layers.  Error-detection and correction capabilities are
   frequently found in lower layers, but are also present in many
   higher-layer protocols in order to detect residual bit errors and
   bugs that introduce errors.  For example, IPv4 verifies a simple
   header checksum before processing inbound packets, even when running
   over a data link, such as Ethernet, that already performs a stronger
   CRC.  TCP and UDP segments further include 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 networking systems from
   many causes other than channel noise [SP00].  Although coding of data
   on the channel can reduce the impact of channel noise, and CRCs
   across each link in a network path can catch many channel-induced
   errors, end-to-end checksums across the entire network path are
   understood to be necessary for applications requiring certainty that
   the data received is error-free [SGHP98].

   The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838]
   is founded on an overlay of Bundle Agents (BAs).  These Bundle Agents
   forward data units called bundles via the Bundle Protocol [RFC5050].
   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.  The notion of
   reliability used in the basic custody transfer mechanism does not
   take the integrity of bundles into account, but acknowledges a
   bundle's receipt and transfers its custody without verifying its
   internal data integrity in any way.  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 [SRC84].  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.  Here, each convergence-layer check is analogous
   to a data-link check, covering a single hop between Bundle Agents,
   but not the entire network path between source and destination for
   the bundle.

   Within the context of DTN, even stronger convergence-layer adapter
   error detection is not sufficient.  Errors within a BA's device
   drivers, errors due to memory issues within the BA's host, e.g.
   radiation-induced soft errors, and errors introduced from file-system
   corruption cannot be detected by convergence layer adapters, as these



Eddy, et al.             Expires August 28, 2008                [Page 3]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   errors occur in gaps between successive phases of forwarding and
   convergence-layer processing.  In order to ensure integrity of DTN
   bundles forwarded across a system composed of BAs and convergence
   layer adapters, end-to-end computation and verification of checksums
   is required [SRC84].  To detect errors introduced in storage, a
   checksum across the bundle would be verified before the bundle is
   sent to the next hop.

   Within this document, we describe a use of the Bundle Security
   Protocol (BSP) [I-D.irtf-dtnrg-bundle-security] in order to provide
   the desired error-detection service by defining suitable BSP
   ciphersuites.  The design decisions for doing this are painstakingly
   explained in Section 2.  It should be clearly understood by readers,
   implementers, and users that we are not using the BSP in a way that
   provides any level of security, which we explain fully in
   Section 2.1.  The guarantee that we attempt to provide is that
   specific blocks within a received bundle are highly likely to have
   been propagated across the overlay without errors, under the
   assumptions of no malicious activity within or between Bundle Agents
   and no capability to inject forged bundles.  The actual format and
   use of this error-detection mechanism based on the BSP and
   requirements for support are described in Section 3.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.  [RFC2119]

1.1.  Overview of Header and Payload Integrity

   It is worthwhile to take a moment to discuss checksum use in the
   Internet to ensure error-free delivery, as this should provide a
   familiar starting point for the reader.  This can then be used as a
   basis for thinking about error-free delivery of bundles.  We must
   distinguish between the need to verify the integrity and reliability
   of ("protect") carried payloads, and the need to verify the
   reliability of the protocol carrying the payload - i.e. the need to
   also protect the header metadata surrounding the payload that the
   protocol tells itself.

   In IPv4, these two things are implemented separately, with the IPv4
   header checksum covering the header information, while the TCP or UDP
   checksum covers the payload.  The TCP/UDP checksum also covers
   certain important IP header fields - this is the 'pseudo-header'
   check.  In IPv6, the header checksum was removed, to speed up router
   processing as header fields were changed.  The 'pseudo-header'
   checksum of important IPv6 header fields is still there as part of
   the overall payload checksum implemented by TCP, UDP, and other
   protocols.  This upper-layer pseudo-header checksum combines the



Eddy, et al.             Expires August 28, 2008                [Page 4]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   header and payload checks efficiently at the receiving IPv6 endhost
   to prevent misdelivery of packets and protect against corrupted
   payloads.  This checksum is a final end-to-end check across the
   entire IP delivery path - for both header and payload.  It ensures
   that the payload is delivered to the right place, without corruption
   being introduced.

   The TCP and UDP checksum mechanism is frequently criticised for being
   weak in that there are classes of errors it does not detect.  This
   checksum is computed by summing 16-bit values within a packet.  If
   two strings are swapped in position within the packet, the checksum
   can remain unchanged even though the datagram is now different from
   the original, and clearly corrupted.  The UDP convergence-layer
   adapter that has been popularly implemented in DTN stacks relies on
   UDP's usual 16-bit one's-complement checksum (the same algorithm used
   for IPv4 headers and TCP segments) to validate incoming datagrams.
   The proposed TCP-based convergence layer [I-D.irtf-dtnrg-tcp-clayer]
   relies on the same checksum algorithm.  This checksum algorithm is
   remarkably useful in its position covering an entire network path and
   ability to detect all errors introduced, even though its overall
   strength against errors is considered weak, and in more recent
   transport protocols has been reconsidered; for instance, SCTP uses
   the CRC-32c algorithm instead [RFC3309].  It is the ability to
   provide a check that the packet at the destination is the same at the
   source that is most useful for Internet traffic; overall strength is
   secondary to this.  The UDP- and TCP- convergence layers and their
   checksums are only useful for one 'bundle hop' between peer agents
   across the Internet, and will not cover multiple bundle hops as an
   end-to-end checksum.

   It would be possible for all intermediate routers in the terrestrial
   Internet to verify the upper-layer pseudo-header checksum at each hop
   rather than just checking data-link CRCs, but, in an efficiency
   tradeoff, this is not normally done.  (Network Address Translation,
   where the change in pseudo-header addresses affects the checksum
   value, is an exception to this.)  Not checking the payload at every
   hop takes advantage of the closed-loop nature of fast Internet
   communication; the cost of packet delivery is cheap, so necessary
   protection against corrupted packets or headers need only be done at
   the last possible moment with a check at the endhost, as the costs
   incurred in delivering the packet to that node, and any resent
   packets to that node, are minuscule.  It is the cheap cost of
   resending and the tight end-to-end control loop which can permit
   reliability checks to be pushed up to or only done at the application
   layer, in accordance with the end-to-end principle, without adversely
   affecting overall communication efficiency.

   In challenged delay-tolerant networks, the network capacity,



Eddy, et al.             Expires August 28, 2008                [Page 5]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   forwarding and storage costs for bundles are far higher, as are the
   costs of getting a resent bundle.  This produces a longer, slower,
   control loop and alters the cost/benefit tradeoff.  It becomes
   worthwhile for intermediate bundle nodes to check all content for
   error-free correctness before forwarding it, to prevent incurring
   unnecessary transmission costs and to also increase the possibility
   of getting the bundle from the source or from over the previous hop
   again if it needs to be resent, shortening the overall resend time.
   Due to the more open-loop nature of communication across delay-
   tolerant and disrupted networks, applications do not communicate as
   well or as easily as they do in the traditional Internet, meaning
   that the the efficiency tradeoff for application-only checks is such
   that DTN application performance will increase with earlier detection
   of errors and earlier resends within the network.

   This shift in costs caused by the difficulty of resending
   information, when compared to the traditional Internet, makes
   verifying the correctness of the header and payload content at each
   bundle node much more important, to permit faster resends and
   conserve storage and transmission capacity.  The Bundle Protocol, as
   specified in [RFC5050], does neither of these things.  Nor does the
   Bundle Protocol protect itself end-to-end.  There is no Bundle
   Protocol check on header or payload at destination bundle nodes;
   there is no end-to-end equivalent to the two checks that the TCP/UDP
   checksum so neatly combines and provides for Internet traffic.  There
   is a need for a check at intermediate nodes in challenged networks,
   given the cost tradeoffs, yet those nodes cannot take advantage of a
   precomputed end-to-end checksum unless one is first provided for
   them.

   This document lays out an unsatisfying way to redress this lack of
   robustness in the existing Bundle Protocol in Section 3, and
   carefully describes the drawbacks to this method in Section 4 and
   Section 5.


2.  Use of the Payload Integrity Block

   The BSP defines three types of blocks:

   o  the Bundle Authentication Block (BAB),

   o  the Payload Integrity Block (PIB),

   o  the Payload Confidentiality Block (PCB).

   Algorithms applied within each of these blocks could be reused to
   detect errors introduced in bundle contents.  However, based on the



Eddy, et al.             Expires August 28, 2008                [Page 6]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   different design goals motivating these three block types, the PIB is
   the only candidate that is truly suitable for supporting the type of
   checksum fields needed to yield end-to-end reliability of received
   bundles.

   The BAB is intended to operate along a single hop within a DTN
   overlay network, and due to the issues discussed in the previous
   section, even an end-to-end chain of hops using the BAB over each hop
   is not sufficient for ensuring reliability.

   The PCB is primarily concerned with the operation of privacy
   transforms over a bundle's contents, which are intended to
   significantly alter and disguise the protected data while in transit,
   rather than simply performing consistency checks over untransformed
   data.

   The PIB is intended to be used end-to-end; that is, by two endpoints,
   rather than hop-by-hop at each intermediate point.  The PIB is
   intended to be used with sets of cryptographic algorithms
   (ciphersuites) that provide Message Authentication Codes (MACs) or
   signatures over bundle or block contents.  MAC and signature
   algorithms are security constructions that may allow verification of
   a legitimate sender (authentication), detection of in-transit
   tampering (integrity), and proof of a particular sender (non-
   repudiation).  As a consequence of the integrity goal, which is based
   on the assumption of an adversary that can alter messages in-flight,
   MACs and signatures can also be effective at detecting errors that
   occur without the presence of an attacker and in the absence of any
   malicious intent (e.g. due to bit errors within transmission media,
   file system corruption, etc.).  Since the PIB uses the BSP's mutable
   canonicalization and covers the Primary Bundle Block, the EIDs and
   other data influencing forwarding and delivery of payloads are also
   protected by the MACs or signatures in addition to the payload data.

   The error-detecting and rejecting capabilities of a MAC or signature
   are similar to those of more-simple checksum algorithms that are
   intended only for error-detection.  In fact, several popular MAC and
   signature constructions use checksums as primary components.  For
   instance, the MD5 hash (checksum) algorithm [RFC1321] is used within
   the HMAC-MD5 keyed-hash MAC construction [RFC2104].  Computationally,
   for large messages, the efficiency of a security construction
   providing integrity is similar to that of a simple checksum, although
   for short messages, it may be much worse.  For instance, HMAC
   requires multiple applications of the underlying hash function, with
   the final one being over a very short input, but if the message
   itself fits within a single block, this results in twice the overhead
   compared to a simple checksum.  Thus, assuming large bundles in
   relation to the block size of typical hash functions, the PIB can



Eddy, et al.             Expires August 28, 2008                [Page 7]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   provide end-to-end error-detection capability for bundles from the
   standpoints of both reasonable effectiveness and reasonable
   computational cost.

2.1.  Differences from Intended Use of the Payload Integrity Block

   The main difference between any simple error-detecting checksum and a
   security construction designed for integrity is that the security
   construction requires keying material.  Key management is recognized
   as an outstanding problem within the DTNRG
   [I-D.irtf-dtnrg-sec-overview] and thought to be quite difficult
   [I-D.farrell-dtnrg-km].  Key management in well-connected systems,
   such as the Internet, is difficult itself, without the additional
   complications of a DTN networking environment.  However, if using a
   keyed security construction for simple error-detection, the secrecy
   of the key is unimportant, and a feasible approach is to specify a
   hard-coded key that all nodes use in the error-detection mechanism
   (e.g. the NULL ciphersuite in LTP's authentication extension is one
   example [I-D.irtf-dtnrg-ltp-extensions]).  Using this approach,
   existing keyed ciphersuites defined for the PIB could be used with
   NULL keys to provide an error-detection mechanism, without requiring
   a key management mechanism.  However, this key-based method reuses a
   security mechanism for error detection, which it is not designed for.
   As there the Bundle Protocol has no separate outer error detection
   wrapping this security payload, if a private key is used, then third-
   party nodes that do not possess that secret key cannot determine the
   reliability of the content, and would be unable to prevent further
   forwarding of errored bundles, leading to decreased performance of
   the delay-tolerant network for resends, due to the open nature of its
   control loop as discussed above.

   The only PIB ciphersuite included in the BSP to date is PIB-RSA-
   SHA256, which creates and verifies signatures of bundles using RSA
   asymmetric-key operations over a SHA-256 hash of the bundle.  The
   length of the SHA-256 output is excessive for providing simple error-
   detection on all but extremely large bundles and the overhead of SHA-
   256 and RSA calculations is also disadvantageous.  It would also
   require some small change in either security block metadata bits or
   the block type field to signal that the special (unsecure) NULL key
   pair for error-detection only was to be used with PIB-RSA-SHA256.
   But the biggest problem with PIB-RSA-SHA256 is the bulk of code
   needed to support the RSA operations, which include bignum math and
   modular arithmetic libraries.  Since error-detection and rejection is
   a vital and absolutely essential component of reliable networking
   protocols, and much of the purpose of the DTN architecture is to
   enable internetworking of devices with limited resources, e.g. motes,
   it would be burdensome on limited low-end embedded systems to require
   all Bundle Protocol implementations to include RSA code.



Eddy, et al.             Expires August 28, 2008                [Page 8]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   Furthermore, RSA was historically patent-encumbered, and this is very
   typical of modern asymmetric-key cryptography techniques in general,
   so although the RSA patents have expired, we are hesitant to require
   implementation of asymmetric-key techniques unless needed for
   security purposes.

   The BAB-HMAC ciphersuite that uses SHA1 [RFC3174] within the HMAC
   construction (HMAC-SHA1) has been specified as mandatory for BSP
   support.  Even though the BAB is not appropriate for end-to-end
   error-detection, it is certain that BSP implementations will include
   HMAC-SHA1 routines, and that creating another ciphersuite for PIB-
   HMAC (which does not exist in the base BSP specification) would
   impose very little additional code.  Partial support for the BSP's
   elements (at least the PIB's format and mutable canonicalization)
   could be made mandatory in the Bundle Protocol along with support for
   the PIB-HMAC ciphersuite with NULL keys while retaining as optional
   all of the other components of the BSP (BAB, PCB, and other
   ciphersuites).  This path seems to be desirable in that it allows re-
   use of existing code along with re-use of existing specifications,
   but does not significantly burden lightweight implementations or
   deployments unconcerned with overlay-layer security.  This approach
   is followed in Section 3 within this document.

   Our previous proposal to add checksumming to bundles defined a new
   block type for carrying error-detecting checksums computed over the
   bundle payload.  This was motivated by the fact that some deployments
   on limited hardware within closed networks will not desire to run
   heavyweight security protocols, nor include the full BSP and its
   mandatory ciphersuites within their code footprints.  Another
   motivation was the desire to avoid creating a false sense of security
   by using a mechanism labelled the Bundle _Security_ Protocol with
   either a ciphersuite or NULL key that provides absolutely no security
   services.  For instance, if an implementation allowed this to be
   configured using the same mechanisms or policy directive
   configuration files, formats, etc. that are normally used to
   configure BSP mechanisms providing real security, then a
   misconfiguration or misunderstanding could have a negative security
   impact to an operational system.

   In order to allay these concerns, it was decided to define simple
   error-detection ciphersuites with the string "INSECURE" in their
   mnemonics and draw a line as to which portions of the BSP security
   framework become mandatory and which remain optional.  This allows
   implementation of error-detection capabilities either with or without
   the majority of the BSP, and with reduced potential for misleading
   users with regards to security.

   Implementations that provide both the full BSP and simple error-



Eddy, et al.             Expires August 28, 2008                [Page 9]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   detection ciphersuites SHOULD subjectively ensure that their
   configuration by users is sufficiently dissimilar from the normal BSP
   configuration.  Implementations MUST NOT implement the "INSECURE"
   ciphersuites in such a way that leads to their being construed as
   security mechanisms in logging output or configuration directives.


3.  INSECURE Ciphersuites

   Any PIB ciphersuite providing only integrity checking for error-
   detection and is unkeyed MUST contain the string "INSECURE" in its
   mnemonic.  PIBs that use these ciphersuites are otherwise
   indistinguishable from PIBs used to implement security services.
   PIB-HMAC is keyed, and so does not use "INSECURE" in its name.  When
   used with a secret key, PIB-HMAC is useful for security, although
   this is not the case when it is used with a NULL key, we assume that
   the presence of a NULL key in the configuration significantly alerts
   users to the fact that it is not providing security.

   To provide the desired functionality, three new ciphersuites are
   defined in this document (PIB-HMAC used with either real or NULL
   keys, PIB-INSECURE-MD5, and PIB-INSECURE-CRC32).  The motivations
   behind defining all three of these ciphersuites are outlined below in
   the more detailed description of each ciphersuite.  All of the
   ciphersuites defined here use the mutable canonicalization algorithm
   that is defined in the BSP and compute their checksums over the
   canonical forms of bundles.  Since error-detection support is
   essential in any sane protocol design and should be mandated in the
   design, this means that the minimal BSP elements that all Bundle
   Protocol implementations MUST support include:

   1.  Mutable Canonicalization - fully described in Appendix A.1 of
       this document.

   2.  PIB wire-format - fully described in Appendix A.2 of this
       document.

   3.  PIB-HMAC ciphersuite with NULL key definition, PIB-INSECURE-MD5
       and PIB-INSECURE-CRC32 ciphersuite

   The new ciphersuites are identified by the following ciphersuite IDs
   within the abstract security block:

   o  0x04 - PIB-HMAC

   o  0x05 - PIB-INSECURE-MD5





Eddy, et al.             Expires August 28, 2008               [Page 10]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   o  0x06 - PIB-INSECURE-CRC32

   PIB-HMAC is defined to use the same HMAC-SHA1 construction as the
   BSP's BAB-HMAC ciphersuite, and can thus leverage existing code.
   Three ciphersuite parameters are needed, all of which are SDNVs.  The
   first SDNV is a key identifier.  A zero value in the key identifier
   field of a PIB using the PIB-HMAC ciphersuite indicates that the
   algorithm is keyed with the special NULL key.  The NULL key used here
   is defined to be 0xc37b 7e64 9258 4340 bed1 2207 8089 4115 5068 f738,
   the same fixed NULL key used with LTP's NULL ciphersuite.  The later
   two EIDs are offsets describing the protected bits of the bundle,
   identical to the offset and length parameters describe in the BSP's
   PIB-RSA-SHA256 ciphersuite.  The first identifies the first covered
   octet and the second identifies the last covered octet.

   PIB-HMAC creates a ten-octet security result and should provide
   adequate error-detection capabilities for large bundles of at least
   several gigabytes in size.  Its advantage lies in that the NULL-keyed
   version can be implemented with minor additions to existing BSP
   codebases, and support for HMAC-SHA1 is known to only require around
   200 lines of portable C code for implementations that do not already
   contain BSP support.

   The existence of the PIB-INSECURE-MD5 ciphersuite is motivated by the
   fact that an MD5 checksum can be computed on the order of twice as
   fast as a SHA1 checksum over the same data, as demonstrated by
   benchmarking activities [RFC1810], yet still yields robust error-
   detection over fairly large inputs.  This may be desirable in
   environments that have only limited computational resources to expend
   on bundle generation or processing.  For instance, the authors have
   implemented generation of bundles of up to several hundred megabytes
   in size, onboard an imaging satellite solid-state data recorder using
   only a 200 MHz processor.  The PIB-INSECURE-MD5 parameters consist of
   two SDNVs, an offset and length, that convey the covered portion of
   the bundle, in an identical way to the corresponding PIB-HMAC and
   PIB-RSA-SHA256 parameters.

   The security result included with the PIB-INSECURE-MD5 ciphersuite is
   a full 16-octet MD5 output.  The longer security result than PIB-HMAC
   may provide better error-detection for very large bundles, in
   addition to being faster to compute.  For small bundles, the lack of
   the HMAC construction's second application of the hash function also
   improves efficiency in PIB-INSECURE-MD5 compared to PIB-HMAC.
   Implementations of MD5 are known to require only around 200 lines of
   portable C code and are widely available as open-source and within
   the MD5 RFC [RFC1321].

   The PIB-INSECURE-CRC32 ciphersuite is intended for small bundles, and



Eddy, et al.             Expires August 28, 2008               [Page 11]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   SHOULD only be used on bundles whose payload length is less than
   65535 bits, because its protection weakens for longer payloads due to
   the increased risk of collisions [Koopman].  The parameters included
   with this ciphersuite are identical to those used with PIB-INSECURE-
   MD5.  The security result is computed using the CRC-32c algorithm,
   identically to that defined for use with SCTP [RFC3309].  The
   security result is always a 4-octet quantity when PIB-INSECURE-CRC32
   is used.  The advantage of this checksum is that it implies a lower
   header overhead to in-flight or in-memory bundles with small
   payloads, in comparison to the length of the PIB-HMAC and PIB-
   INSECURE-MD5 security results.  This may be highly desirable in
   environments where small messaging bundles are normal and only
   bandwidth-limited links are available.  The CRC-32c algorithm is
   known to be implementable in only a few dozen lines of portable C
   code.

3.1.  Generation and Processing Rules

   Since the INSECURE ciphersuites and NULL-keyed PIB-HMAC use the same
   block type code and format as the more secure uses of PIB, they
   inherit the existing generation and processing rules of the PIB.
   This is good from a security standpoint in two respects:

   1.  The existing PIB processing rules consider interaction with any
       BABs that might be added to a bundle and prevent interactions
       that would cause wrongful failure of MACs, signatures, and
       checksums.

   2.  The PIB and PCB processing rules remove the possibility of a MAC,
       signature, or checksum revealing information about the private
       contents of the PCB via the ordering of the applied security/
       error-detection transforms.  This is discussed within the PCB-
       RSA-AES128-PAYLOAD-PIB ciphersuite definition in the BSP
       specification.

   Although the BSP was intended as an optional suite of extensions to
   the Bundle Protocol, and only needed in cases where certain security
   services are desired at the bundle layer, a subset of its components
   is always needed to implement the PIB-based error-detection
   mechanism.  As providing error detection is necessary to ensure
   reliable delivery of bundles, these MUST always be supported in any
   implementation of the Bundle Protocol, since error-detection must be
   an essential property of the Bundle Protocol.  To be very clear,
   error-free delivery does not require mandatory implementation of the
   full BSP and accompanying security ciphersuites, but only requires
   the PIB block format, and the mutable canonicalization rules.  These
   two portions of the BSP are fully described in the BSP specification
   [I-D.irtf-dtnrg-bundle-security] with some commentary regarding their



Eddy, et al.             Expires August 28, 2008               [Page 12]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   use for error-detection in Appendix A of this document.

   When applications request custody transfer, the generated bundles
   MUST use an unkeyed or NULL-keyed PIB ciphersuite defined in this
   document between the source and destination bundle agents.  Private
   keys cannot guarantee reliable hop-by-hop delivery, increasing the
   time to error detection at the end nodes and the time required for
   resends.  For other bundles, not requiring custody transfer, an
   unkeyed or NULL-keyed PIB ciphersuite SHOULD be used.

   Checking of unkeyed or NULL-keyed PIBs at intermediate bundle agents
   SHOULD be performed, when possible, and an agent which fails to match
   the PIB security result within a bundle SHOULD immediately discard
   the bundle.  This limits the wasted resources involved in propagating
   data now known to be errored.  A future version of the Bundle
   Protocol might include a bundle processing flag that signals that
   errored-delivery is acceptable to a receiving application.  However,
   the current version does not define such a flag.  A future version of
   the Bundle Protocol specification might also define an administrative
   record that signals when a bundle has been dropped due to a
   corruption event detected via an unkeyed or NULL-keyed PIB check;
   that has not been defined in the current Bundle Protocol.


4.  Performance Considerations

   The normal method for handling error detection with security is to
   cover the encrypted payload with an outer error-detecting checksum
   wrapper.  Use of an end-to-end private key without a separate end-to-
   end outer error-detecting checksum prevents determination of the
   bundle's fidelity by any in-path forwarding nodes lacking that
   private key.  This discourages interoperability between parties that
   do not share keys, and consumes more network resources in relaying an
   errored bundle to the receiving destination end node, and in
   resending the bundle once the error is finally detected on
   decryption.  Custody transfer guaranteeing error-free receipt at
   intermediate nodes is not possible with private keys in the mechanism
   outlined above.  When private keys are in use, errors introduced into
   bundles can only be detected at the decoding endpoint, rather than at
   intermediate nodes, meaning that resends across the entire network
   are requested far later when security is in use.  This means that
   applications using unencrypted traffic can be expected to outperform
   applications using private keys in DTN networks, thanks to their
   ability to detect errors earlier, their smaller resend control loops
   to get replacement bundles, and their meaningful use of custody
   transfer.

   Again, an outer error-detecting checksum around the encrypted or



Eddy, et al.             Expires August 28, 2008               [Page 13]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   unencrypted bundle prevents these problems, and allows custody
   transfer to be meaningful for encrypted traffic.


5.  Security Considerations

   This document has attempted to assuage any security concerns that
   would result from applying non-security-providing algorithms within a
   mechanism intended for security.  This is accomplished through
   semantic overloading of the PIB, reusing its structure to hold a
   simple checksum when it is not intended to provide security services.

   The potential leakage of information if checksums are not covered by
   some BSP confidentiality transform that is applied later in the
   transmission path is eliminated by the fact that the existing PIB
   block type code is used, and the BSP itself already contains rules
   for ensuring that confidentiality transforms applied by the PCB
   protect the security result fields within PIB instances.

   This design decision to reuse a security block for error-detection
   may seem bizarre to both security and networking experts unfamiliar
   with the travails of the IRTF DTN research group.  However, this
   decision was necessitated by the late addition of checksum support to
   the Bundle Protocol.  By the time this work was recognized by the
   group as necessary by the group, the Bundle Protocol itself was in
   final review phases and had been implemented multiple times.  The
   Bundle Security Protocol was also no longer malleable enough to
   ensure compatibility with checksum support, as it had obtained a
   level of relative stability in its specification and there were
   existing implementation efforts based on these which could have
   required modification in order to not pass checksums carried in a
   non-BSP block as unprotected after performing a confidentiality
   transform of the payload.

   Ideally, the error-detection functions would be implemented within
   the basic networking portions of the Bundle Protocol, and not as a
   subset of the security framework.  However, the existing Bundle
   Protocol design was too well-established for the current definition
   of the Bundle Protocol to be affected.  Since at this time, the
   Bundle Protocol has only been proposed as Experimental with some
   disclaimers, this situation is temporarily palatable.  It is well-
   understood that future revisions of the Bundle Protocol need to
   provide mechanisms ensuring error detection for reliable delivery.
   In order to limit overhead, shorter checksums, e.g.  CRC-16, could be
   used for small blocks, with longer checksums, e.g.  MD5, reserved for
   large payload blocks.  This would allow checksums to cover and
   provide confident processing of even blocks with mutable fields, and
   retain efficient updating in-network as a mutable field changes,



Eddy, et al.             Expires August 28, 2008               [Page 14]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   without the recomputation also covering large unchanging payload
   blocks.  This might also constrain the damage caused by errors to the
   functions provided by an individual block, rather than affecting the
   whole bundle and causing the whole bundle to be discarded, although
   the overall value of this is currently unknown.

   The need to conserve limited network resources by detecting and
   avoiding further propagating errored bundles in-transit means that
   Bundle Agents SHOULD always validate checksums of in-flight bundles,
   even if the Agents are not the ultimate destination.  This opens the
   door for a potential denial-of-service attack on DTN Bundle Agents by
   forcing them to expend computational cycles on bundles with large
   payloads.  In this case, the attacker would also have to send these
   bundles over some link towards the target Bundle Agent, which will
   often be more constrained in bandwidth or availability than the
   Bundle Agent is in compuational cycles, so this threat may be
   unrealistic, or better combatted through access-control on links.  If
   this threat does turn out to be realistic in some set of
   circumstances, intermediary validation of PIBs was intentionally left
   as a SHOULD-level activity rather than a MUST, and could be
   dynamically disabled at some threshold of CPU use.

   Using the same protocol mechanism to provide (1) error-detection
   without security claims, (2) error-detection using a security
   protocol insecurely-keyed with a known NULL key, and (3) actual
   security protection using the same protocol but with secret keys, any
   of which can defined and used in the same "Payload Integrity Block",
   is confusing at best, and not a good clean-sheet approach to helping
   ensure secure configurations, interoperable implementations, or
   efficient handling of errored bundles.

   Use of a NULL key is inferior to separately handling the security
   concerns of sender-authentication and integrity-protection from that
   of error-checking as it opens the door to private keys that prevent
   standalone error-detection, and should be discouraged.  Also, the
   NULL key cannot provide error-detection needed for the mutable parts
   of the bundle.  Providing any error detection for the mutable parts
   of the bundle has not been done here, and reliance on the fidelity of
   mutable payloads should be avoided for this reason.


6.  IANA Considerations

   This document has no considerations for IANA.







Eddy, et al.             Expires August 28, 2008               [Page 15]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


7.  Acknowledgements

   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).

   Discussion in the DTNRG and particular suggestions from
   (alphabetically) Mike Demmer, Stephen Farrell, Darren Long, Peter
   Lovell, and Susan Symington guided the genesis of this document and
   were crucial to adding limited error-detection capabilities to the
   Bundle Protocol within the existing pre-established security
   framework.


8.  References

8.1.  Normative References

   [I-D.irtf-dtnrg-bundle-security]
              Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification",
              draft-irtf-dtnrg-bundle-security-05 (work in progress),
              February 2008.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3309]  Stone, J., Stewart, R., and D. Otis, "Stream Control
              Transmission Protocol (SCTP) Checksum Change", RFC 3309,
              September 2002.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.







Eddy, et al.             Expires August 28, 2008               [Page 16]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


8.2.  Informative References

   [I-D.farrell-dtnrg-km]
              Farrell, S., "DTN Key Management Requirements",
              draft-farrell-dtnrg-km-00 (work in progress), June 2007.

   [I-D.irtf-dtnrg-ltp-extensions]
              Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
              Transmission Protocol - Extensions",
              draft-irtf-dtnrg-ltp-extensions-06 (work in progress),
              October 2007.

   [I-D.irtf-dtnrg-sec-overview]
              Farrell, S., Symington, S., Weiss, H., and P. Lovell,
              "Delay-Tolerant Networking Security Overview",
              draft-irtf-dtnrg-sec-overview-04 (work in progress),
              February 2008.

   [I-D.irtf-dtnrg-tcp-clayer]
              Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
              Convergence Layer Protocol",
              draft-irtf-dtnrg-tcp-clayer-01 (work in progress),
              February 2008.

   [Koopman]  Koopman, P., "32-bit cyclic redundancy codes for Internet
              applications", Proceedings of the International Conference
              on Dependable Systems and Networks (DSN), pp. 459-
              468 2002, June 2002.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1662]  Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
              July 1994.

   [RFC1810]  Touch, J., "Report on MD5 Performance", RFC 1810,
              June 1995.

   [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.

   [SGHP98]   Stone, J., Greenwald, M., Hughes, J., and C. Partridge,
              "Performance of checksums and CRCs over real data", IEEE
              Transactions on Networks vol. 6 issue 5, pp. 529-543,



Eddy, et al.             Expires August 28, 2008               [Page 17]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


              October 1998.

   [SP00]     Stone, J. and C. Partridge, "When the CRC and TCP Checksum
              Disagree", Proceedings of ACM SIGCOMM 2000,
              September 2000.

   [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-end Arguments
              in System Design", ACM Transactions on Computer Systems 2
              (4), November 1984.


Appendix A.  Mandatory BSP Elements Needed to Implement Error-Detection

   This document makes some BSP components mandatory to Bundle Protocol
   implementations, while the BSP was previously entirely optional.  The
   appendix discusses these elements in greater detail, and highlights
   some further drawbacks of basing error detection and protocol
   reliability upon them.

A.1.  Mutable Canonicalization

   While impressively named, the mutable canonicalization procedure is
   actually quite simple to understand.  The requirement for mutable
   canonicalization stems from the Bundle Protocol's forwarding design
   that allows several "mutable" fields (e.g. the "dictionary",
   custodian, and some flags and length fields), to change in-transit at
   intermediate nodes.  In order for the checksum, MAC, or signature
   computed and placed in the security result of a sent PIB to match the
   result computed over the received bundle, the sender and receiver
   need to leave mutable fields out of these computations.  The format
   of a bundle that is input to the PIB algorithms thus differs from its
   wire-format, and is called its "mutable canonicalization".

   Using mutable canonicalization implies either using an incrementally-
   updatable checksum algorithm and feeding many small pieces of data to
   it, or entirely rewriting a bundle block-by-block based on mutable
   canonicalization rules before feeding it to the checksum function.
   (The mutable fields still require protection against errors; a hop-
   by-hop checksum over only the mutable fields could be used to provide
   this.  Hop-by-hop checksum coverage could be provided by a
   convergence layer, but this would likely cover the entire bundle or
   fragment.  Some proposed convergence layers do not provide any form
   of checksum to compensate for this oversight in bundle design.)

   Several problems are known to plague mutable canonicalization:

   1.  The Bundle Protocol specification describes the bundle processing
       control flags as a single variable-length SDNV whose bits are



Eddy, et al.             Expires August 28, 2008               [Page 18]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


       sub-divided in-order by function into "SRR" (Status Report
       Request), "COS" (Class of Service), and "General".  The BSP's
       mutable canonicalization description shows three separate fields,
       with only slightly differing names, but in totally opposite
       order: "Proc.  Flags", "COS Flags", and "SRR Flags", instead of
       one single SDNV, yet has text that describes operating on these
       as a single 64-bit value and applying a fixed-length mask to
       them.  This is unclear at best, and feared to be uninteroperable
       in implementations.

   2.  Many bits within the bundle processing control flags are masked
       out (i.e. forced to zero within) the mutable canonicalization
       format.  This includes all of the reserved class of service (COS)
       bits that are highly likely to be needed to overcome the
       limitation of having only three defined priority levels in the
       Bundle Specification (compare to DiffServ, CLNP's priority field,
       Aeronautical Mobile Radio Service message priorities, or
       mechanisms in other networking stacks that provide many more
       bits).  This means that these bits, and any other bundle
       processing control bits, will be unprotected by the end-to-end
       checksum and may change in-transit, potentially causing mis-
       treatment or mal-delivery of bundles.

   3.  The existing "bundle is a fragment" bit is unprotected in mutable
       canonicalization.  Errors in this bit itself can probably be
       caught through other means, such as careful length and bound
       checking in processing the rest of the bundle.

   4.  The entire mutable canonicalization procedure of parsing and re-
       formatting bundles in order to perform a checksum validation is
       significantly more complex than is typical in most existing
       protocols that are designed to be capable of simply computing a
       validation over a frame either without modifications [RFC1662],
       with only a small fixed-length and position field masked
       [RFC0791], or with only a simple fixed-size pseudoheader
       [RFC0793].  The significant additional complexity of mutable
       canonicalization prevents high performance in forwarding nodes
       that follow the guideline of verifying unkeyed or NULL-keyed
       PIBs.

A.2.  PIB Format

   PIBs follow the format of the abstract security block, defined in the
   BSP specification [I-D.irtf-dtnrg-bundle-security], with a block type
   code that identifies them as PIBs.  Some of the processing rules for
   PIBs that make the PIB less than ideal for error-detection purposes
   include:




Eddy, et al.             Expires August 28, 2008               [Page 19]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


   1.  If a PCB is placed into a bundle that already has a PSB, then
       another PCB is created that hides the PIB.  This means that for
       end-to-end error-detection PIBs, any in-network security proxies
       that add PCB blocks also prevent the checksum in the PIB from
       being verifiable before the PCB's security destination recovers
       the cleartext PIB.  If the PCB security destination is never
       reached, the bundle cannot be checked for errors.  Errored
       bundles will consume resources between these two security
       gateways, since the errors cannot be detected and the bundles
       discarded en route.  The RSA signature of such an errored bundle
       will only fail at the security destination, and the bundle will
       only be discarded at that end point, but there may be significant
       resources expended in delivering the useless bundle to that
       point.

   2.  A previously-generated PIB's security result cannot be retained
       outside a PCB in the clear, because an observer could correlate
       the value to some known probable plaintext payload value.  It
       might be better to reverse the order of operations and always
       generate rewritten PIB ciphersuite checksums after generating
       PCBs that encrypt the payload, so that the PIB security result
       covers the PCB's encrypted form of the payload rather than the
       unencrypted form, and uses the same security destination as the
       PCB.  Upon reaching this security destination, another PIB
       destined for the receiver, covering the payload revealed at the
       security destination, could be generated.  Requiring this would
       allow detection of errored bundles between PCB security source
       and PCB security destination, but would involve adding another
       instruction to the PCB generation process within the BSP.  This
       assumes no errors are introduced during the decryption process of
       the PCB, as such errors would go undetected.  If bundles pass
       through nested security domains, this could compound the error
       rate.

   There seems to be both benefits and drawbacks to any approach to PIB
   and PCB interaction that does not involve layering multiple PIBs that
   can be pushed and popped off of a bundle at various security sources
   and destinations.  Pushing and popping nested PSBs approximates the
   outer checksum around inner security payload used successfully
   elsewhere in networking.  By some reasonable metrics, the BSP-
   prescribed interaction that we have attempted to build on and fix
   here may be among the least desirable of known methods for error-
   detection.








Eddy, et al.             Expires August 28, 2008               [Page 20]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


Authors' Addresses

   Wesley M. Eddy
   Verizon Federal Network Systems
   NASA Glenn Research Center
   21000 Brookpark Rd, MS 54-5
   Cleveland, OH  44135
   United States of America

   Phone: +1-216-433-6682
   Email: weddy@grc.nasa.gov


   Lloyd Wood
   Cisco Systems
   11 New Square Park, Bedfont Lakes
   Feltham, Middlesex  TW14 8HA
   United Kingdom

   Phone: +44-20-8824-4236
   Email: lwood@cisco.com


   Will Ivancic
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   USA

   Phone: +1-216-433-3494
   Fax:   +1-216-433-8705
   Email: William.D.Ivancic@nasa.gov



















Eddy, et al.             Expires August 28, 2008               [Page 21]


Internet-Draft        Bundle Checksum Ciphersuites         February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Eddy, et al.             Expires August 28, 2008               [Page 22]