Network Working Group W. Eddy
Internet-Draft Verizon
Expires: February 15, 2008 L. Wood
Cisco Systems
August 14, 2007
The DTN Bundle Protocol Payload Checksum Block
draft-eddy-dtnrg-checksum-00
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 February 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Eddy & Wood Expires February 15, 2008 [Page 1]
Internet-Draft Bundle Protocol Checksum August 2007
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
without errors having been introduced. This document partially
rectifies the situation by defining a Bundle Protocol extension for
carrying payload checksums and describes how its use can be
integrated with both custody transfer and fragmentation.
Table of Contents
1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Payload Checksum Block Format . . . . . . . . . . . . . . . . 5
2.1. Checksum Algorithms . . . . . . . . . . . . . . . . . . . 6
3. Rules for Use . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Eddy & Wood Expires February 15, 2008 [Page 2]
Internet-Draft Bundle Protocol Checksum August 2007
1. Motivations
Reliable transmission of information is a well-known problem for all
protocol layers. Error detection and correction capabilities are
found in lower layers, but are also present in many higher-layer
protocols in order to detect residual bit errors and bugs. For
example, IPv4 verifies a simple header checksum before processing
inbound packets, even when running over a data link like Ethernet
that already performs a stronger CRC, and TCP and UDP segments
further includes 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 packets from causes other than channel noise [SP00].
Although coding of data on the channel can reduce the impact of
channel noise, end-to-end checksums are understood to be necessary
for applications requiring relative certainty that the data received
is error-free [SG98].
The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838]
is founded on an overlay of Bundle Agents (BAs), that forward data
units called bundles via a Bundle Protocol [SB07]. 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. Unfortunately, the notion of
reliability used in the basic custody transfer mechanism does not
take bit errors into account. 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 [RFC4838]. 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.
For example, the UDP convergence-layer adapter that has been
popularly implemented in DTN stacks uses the usual IP 16-bit one's-
complement checksum to validate incoming packets. This checksum is
computed by summing 16-bit values within a packet. If two strings
within the packet of size greater than 16 bits are swapped in
position, the checksum will pass even though the datagram is now
different from the original, and clearly errored. The proposed TCP-
based convergence layer relies on the same checksum algorithm. This
checksum algorithm is considered weak, in that it does not detect a
class of subtle errors, but at least an attempt to verify that the
packet was as sent has been made.
Eddy & Wood Expires February 15, 2008 [Page 3]
Internet-Draft Bundle Protocol Checksum August 2007
Even stronger convergence-layer adapter error detection is not
sufficient. Errors within a BA's memory, errors due to memory issues
within the BA's host, e.g. radiation-induced soft errors, or errors
introduced from file-system corruption cannot be detected by
convergence layer adapters, as these errors occur in between
successive phases of forwarding and convergence-layer processing.
End-to-end computation and verification of checksums is required to
ensure integrity of DTN bundles forwarded across a system composed of
BAs and convergence layer adapters [SRC84].
The proposed Bundle Security mechanisms [SFWP07] are capable of
providing an end-to-end checksum, but are intended for the very
different problem of security. The current design of Bundle Security
is not practical for simple integrity checking outside of a more
paranoid security context. For example, the Bundle Security
mechanisms include "mandatory ciphersuites" that implementations must
support. No simple checksum algorithm is among the mandated
algorithms. The mandated ciphersuites do include some more complex
keyed-hash constructions, but these rely on key management, which is
not appropriate for general integrity checking between multiple
parties simply relaying bundles. While it would be technically
possible to graft a non-security integrity-checking mechanism onto
the avaiable security mechanisms by specifying some assumed key, it
would be inapproriate for the problem at hand, and overkill.
Instead, it would be much simpler and less error-prone to implement a
separate checksum block for optional inclusion on bundles. Section 2
of this document defines such a block and Section 3 gives some simple
rules for its use.
Eddy & Wood Expires February 15, 2008 [Page 4]
Internet-Draft Bundle Protocol Checksum August 2007
2. Payload Checksum Block Format
A new bundle block, the Payload Checksum Block, is defined in this
section, for inclusion in bundles where integrity checking is
desirable. An un-keyed checksum algorithm is used. The integrity
verification that it provides covers only the bundle payload, as
several portions of other bundle blocks are allowed (and expected) to
change in-transit as a bundle is forwarded through a DTN. The
implications of this decision are discussed in the next section.
No Endpoint ID references are needed for this, so the layout follows
that of Figure 6 in the Bundle Protocol specification [SB07], with
its use of Self-Delimiting Numeric Values (SDNVs):
+-----------+-----------+-----------+-----------+
|Block Type | Block Processing Ctrl Flags (SDNV)|
+-----------+-----------+-----------+-----------+
| Block Length (SDNV) |
+-----------+-----------+-----------+-----------+
| Checksum Algorithm (SDNV) |
+-----------+-----------+-----------+-----------+
| |
| Payload Checksum Value |
| (variable length) |
| |
+-----------------------------------------------+
Figure 1: Payload Checksum Block Format
The fields shown in Figure 1 above are defined as:
o Block Type - Implementations are currently using a value defined
as experimental in the Bundle Protocol Specification, but can be
expected to transition to an assigned value.
o Block Processing Ctrl Flags - The bits in this SDNV are defined in
the Bundle Protocol Specification. For Payload Checksum Blocks,
none of these bits need be set, except perhaps bit 3, to indicate
the "last block", when the block is sent as the final block in a
bundle.
o Block Length - This SDNV encodes the length of the remainder of
the Payload Checksum Block. When the Checksum Algorithm SDNV is
parsed, its length can be subtracted from the Block Length value
to determine the level of truncation for the Payload Checksum
Value, as explained below.
Eddy & Wood Expires February 15, 2008 [Page 5]
Internet-Draft Bundle Protocol Checksum August 2007
o Checksum Algorithm - This identifies the algorithm used to compute
the Payload Checksum Value field following it. Defined algorithms
are listed below.
o Payload Checksum Value - This is a raw string of octets whose
length is implied by the Block Length. This string contains the
checksum result computed over the Payload Block of the bundle, and
may only contain the high-order bits of this result, if truncation
is used to shorten the length of the checksum, as described below.
2.1. Checksum Algorithms
Any implementation of this specification MUST support the MD5
checksum algorithm [RFC1321]. MD5 has been chosen as the baseline
checksum algorithm in this mechanism because it represents a
reasonable tradeoff between robust error detection and efficiency of
implementation. For widespread use in DTNs, both resource-efficient
implementation and decent error-detection capabilities are needed.
MD5 algorithms are known to achieve processing several Mbps, even on
rather limited hardware [RFC1810], yet MD5 provides a much more
robust checksum than the Internet's 16-bit one's complement checksum.
Although MD5 has cryptographic weaknesses and is discouraged for use
in security protocols, concerns with resistance to pre-image
generation are irrelevant here as we are not using MD5 values in a
security context.
We also have a defined value to indicate use of SHA-1 checksums
[RFC3174]. However, support for SHA-1 checksums is not required.
SHA-1 is significantly less efficient than MD5 to compute in our
experience, for seemingly little added error-detection capability
when truncated to the same length. Implementations SHOULD at least
support receiving and verifying SHA-1 checksums.
An Adler-32 checksum option is also specified, but should be used
only in cases where bundle payloads are relatively small and
efficiency of computation is highly important. Implementations
SHOULD support at least receiving and verifying Adler-32 checksums.
The complete list of currently defined Checksum Algorithm values is:
+---+-----------+---------------------+
| # | Algorithm | Un-Truncated Length |
+---+-----------+---------------------+
| 0 | MD5 | 128 bits |
| | | |
| 1 | SHA-1 | 160 bits |
| | | |
Eddy & Wood Expires February 15, 2008 [Page 6]
Internet-Draft Bundle Protocol Checksum August 2007
| 2 | Adler-32 | 32 bits |
+---+-----------+---------------------+
Other checksum algorithms may be assigned values in future documents.
Eddy & Wood Expires February 15, 2008 [Page 7]
Internet-Draft Bundle Protocol Checksum August 2007
3. Rules for Use
On small payloads, the relatively long output of the MD5 or SHA-1
algorithms might be viewed as a detriment to end-to-end application
performance by increasing the header overhead of the Bundle Protocol,
and reducing the capacity available to higher layers. For this
reason, senders of the Payload Checksum Block are permitted to
truncate the transmitted Payload Checksum Values if the full checksum
algorithm's output is deemed to be overly long in comparison to the
size of the payload. This should be done carefully at the sending
application's discretion, and never by default. When generating or
verifying a truncated checksum, it is understood that only the high-
order octets are included.
The checksum conveyed in the Payload Checksum Block only covers the
Payload Block of a bundle, and does not include any pseudoheaders
with EIDs, timestamps, etc., or any other portion of a bundle or its
other extension blocks. Ensuring robustness of bundle header
information and metadata is a separate problem not addressed here;
ideally each header would be self-checking to guarantee a degree of
robustness on receipt.
The checksum within the Payload Checksum Block has differing
semantics if it occurs before or after the Payload Block. If placed
before the Payload Block, then the Checksum Value should be
understood to cover the entire (unfragmented / reassembled) payload,
whereas if it follows the Payload Block within a Bundle Fragment,
then the Checksum Value only applies to the included fragment of the
payload.
Intermediate Bundle Agents, which may not be affiliated with either
the source nor the destination of a bundle, are permitted to verify
the Payload Checksum Block and attempt local recovery. If local
recovery is not possible, then the bundle MAY be deleted.
This document suggests amending the Bundle Protocol specification
with regard to Custody Transfer. Without any checksum verification,
claiming custody of a bundle is a potentially troublesome operation.
We suggest that the Bundle Protocol specification require the use of
a Payload Checksum Block when Custody Transfer is requested by an
application in order to close this gap.
Eddy & Wood Expires February 15, 2008 [Page 8]
Internet-Draft Bundle Protocol Checksum August 2007
4. Security Considerations
The mechanism described in this document does not introduce any new
security concerns beyond those present in the basic Bundle Protocol.
It only attempts to ensure the reliability of the Bundle Protocol
payload. Ensuring Bundle Protocol header reliability remains an open
problem.
Eddy & Wood Expires February 15, 2008 [Page 9]
Internet-Draft Bundle Protocol Checksum August 2007
5. IANA Considerations
This document has no considerations for IANA.
Eddy & Wood Expires February 15, 2008 [Page 10]
Internet-Draft Bundle Protocol Checksum August 2007
6. 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).
Eddy & Wood Expires February 15, 2008 [Page 11]
Internet-Draft Bundle Protocol Checksum August 2007
7. References
7.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810,
June 1995.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[SB07] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", draft-irtf-dtnrg-bundle-spec-09 (work in
progress), April 2007.
7.2. Informative References
[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.
[SFWP07] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-03 (work in progress),
April 2007.
[SG98] 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.
[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.
Eddy & Wood Expires February 15, 2008 [Page 12]
Internet-Draft Bundle Protocol Checksum August 2007
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 Kingcom
Phone: +44-20-8824-4236
Email: lwood@cisco.com
Eddy & Wood Expires February 15, 2008 [Page 13]
Internet-Draft Bundle Protocol Checksum August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 & Wood Expires February 15, 2008 [Page 14]