Network Working Group W. Eddy
Internet-Draft Verizon
Intended status: Experimental L. Wood
Expires: March 20, 2008 Cisco Systems
W. Ivancic
NASA
September 17, 2007
Checksum Ciphersuites for the Bundle Protocol
draft-irtf-dtnrg-bundle-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 March 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Eddy, et al. Expires March 20, 2008 [Page 1]
Internet-Draft Bundle Checksum Ciphersuites September 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 remedies the
situation by defining ciphersuites for use within the Bundle Security
Protocol's Payload Security Block to provide error-detection
functions regardless of an implementation's support for other, more
heavy-weight, 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
ciphersuite definitions. This document lengthily discusses the pros
and cons of this approach and the discussion points that combined to
drive this design.
Eddy, et al. Expires March 20, 2008 [Page 2]
Internet-Draft Bundle Checksum Ciphersuites September 2007
Table of Contents
1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use of the Payload Security Block . . . . . . . . . . . . . . 6
2.1. Differences from Intended Use of the Payload Security
Block . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. INSECURE Ciphersuites . . . . . . . . . . . . . . . . . . . . 10
3.1. Generation and Processing Rules . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Mandatory BSP Elements Needed to Implement
Error-Detection . . . . . . . . . . . . . . . . . . . 20
A.1. Mutable Canonicalization . . . . . . . . . . . . . . . . . 20
A.2. PSB Format . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Eddy, et al. Expires March 20, 2008 [Page 3]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 like 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, end-to-end
checksums 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
[I-D.irtf-dtnrg-bundle-spec]. 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. 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.
For example, the UDP convergence-layer adapter that has been
popularly implemented in DTN stacks uses UDP's usual 16-bit one's-
complement checksum (the same algorithm used for IPv4 headers and TCP
segments) to validate incoming datagrams. 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
errored. The proposed TCP-based convergence layer
[I-D.irtf-dtnrg-tcp-clayer] relies on the same checksum algorithm.
This checksum algorithm is considered weak, and in more recent
Eddy, et al. Expires March 20, 2008 [Page 4]
Internet-Draft Bundle Checksum Ciphersuites September 2007
transport protocols has been reconsidered; for instance, SCTP uses
the CRC-32c algorithm instead [RFC3309].
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, or errors introduced from file-system
corruption cannot be detected by convergence layer adapters, as these
errors occur in gaps 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].
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]
Eddy, et al. Expires March 20, 2008 [Page 5]
Internet-Draft Bundle Checksum Ciphersuites September 2007
2. Use of the Payload Security Block
The BSP defines three types of blocks:
o the Bundle Authentication Block (BAB),
o the Payload Security Block (PSB),
o the Confidentiality Block (CB).
Algorithms applied within each of these blocks could be pressed into
use to detect errors introduced in bundle contents. However, based
on the different design goals motivating these three block types, the
PSB 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 CB 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 PSB is intended to be used end-to-end; that is, by two endpoints,
rather than hop-by-hop at each intermediate point. The PSB 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 PSB 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
Eddy, et al. Expires March 20, 2008 [Page 6]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 PSB can
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 Security 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
like 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 PSB 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 key cannot determine the
reliability of the content, and would be unable to prevent further
forwarding of errored bundles.
The only PSB ciphersuite included in the BSP to date is PSB-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 computations are also detrimental. It would also require
some small change in either security block metadata bits or the block
Eddy, et al. Expires March 20, 2008 [Page 7]
Internet-Draft Bundle Checksum Ciphersuites September 2007
type field to signal that the special (unsecure) NULL key pair for
error-detection only was to be used with PSB-RSA-SHA256. But the
biggest problem with PSB-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 to require all Bundle Protocol implementations to
include RSA code. 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 PSB-
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 PSB's format and mutable canonicalization)
could be made mandatory in the Bundle Protocol along with support for
the PSB-HMAC ciphersuite with NULL keys while retaining as optional
all of the other components of the BSP (BAB, CB, 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.
Eddy, et al. Expires March 20, 2008 [Page 8]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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-
detection ciphersuites MUST 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.
Eddy, et al. Expires March 20, 2008 [Page 9]
Internet-Draft Bundle Checksum Ciphersuites September 2007
3. INSECURE Ciphersuites
Any PSB ciphersuite providing only integrity checking for error-
detection and is unkeyed MUST contain the string "INSECURE" in its
mnemonic. PSBs that use these ciphersuites are otherwise
indistinguishable from PSBs used to implement security services.
PSB-HMAC is keyed, and so does not use "INSECURE" in its name. When
used with a secret key, PSB-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 (PSB-HMAC used with either real or NULL
keys, PSB-INSECURE-MD5, and PSB-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
mandatory, 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. PSB wire-format - fully described in Appendix A.2 of this
document.
3. PSB-HMAC ciphersuite with NULL key definition, PSB-INSECURE-MD5
and PSB-INSECURE-CRC32 ciphersuite
The new ciphersuites are identified by the following ciphersuite IDs
within the abstract security block:
o 0x04 - PSB-HMAC
o 0x05 - PSB-INSECURE-MD5
o 0x06 - PSB-INSECURE-CRC32
PSB-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 PSB using the PSB-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,
Eddy, et al. Expires March 20, 2008 [Page 10]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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
PSB-RSA-SHA256 ciphersuite. The first identifies the first covered
octet and the second identifies the last covered octet.
PSB-HMAC creates a 10-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 very nearly for free within 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 PSB-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, 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 PSB-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 PSB-HMAC and PSB-RSA-SHA256
parameters.
The security result included with the PSB-INSECURE-MD5 ciphersuite is
a full 16-octet MD5 output. The longer security result than PSB-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 PSB-INSECURE-MD5 compared to PSB-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 PSB-INSECURE-CRC32 ciphersuite is intended for small bundles, and
MUST only be used on bundles whose payload length is less than 65535
bytes. The parameters included with this ciphersuite are identical
to those used with PSB-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 PSB-INSECURE-CRC32 is used. The advantage of this checksum is
that it implies a lower header overhead to on-wire or in-memory
bundles with small payloads in comparison to the length of the PSB-
HMAC and PSB-INSECURE-MD5 security results. This may be highly
Eddy, et al. Expires March 20, 2008 [Page 11]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 several dozen lines of
portable C code.
3.1. Generation and Processing Rules
Since the INSECURE ciphersuites and NULL-keyed PSB-HMAC use the same
block type code and format as the more secure uses of PSB, they
inherit the existing generation and processing rules of the PSB.
This is good from a security standpoint in two respects:
1. The existing PSB 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 PSB and CB processing rules remove the possibility of a MAC,
signature, or checksum revealing information about the private
contents of the CB via the ordering of the applied security/
error-detection transforms. This is discussed within the CB-RSA-
AES128-PAYLOAD-PSB 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 PSB-based error-detection
mechanism. 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, only the PSB block format,
and the mutable canonicalization rules. These two portions of the
BSP are fully described in teh BSP specification
[I-D.irtf-dtnrg-bundle-security] with some commentary regarding their
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 PSB ciphersuite defined in this
document between the source and destination bundle agents. For other
bundles, not requiring custody transfer, an unkeyed or NULL-keyed PSB
ciphersuite SHOULD be used.
Checking of unkeyed or NULL-keyed PSBs at intermediate bundle agents
SHOULD be performed, when possible, and an agent which fails to match
the PSB security result within a bundle SHOULD immediately discard
the bundle. This limits the wasted resources involved in propagating
Eddy, et al. Expires March 20, 2008 [Page 12]
Internet-Draft Bundle Checksum Ciphersuites September 2007
known-errored data. 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 PSB check; this has not been
defined in the current Bundle Protocol.
Eddy, et al. Expires March 20, 2008 [Page 13]
Internet-Draft Bundle Checksum Ciphersuites September 2007
4. 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 PSB, 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 PSB
block type code is used, and the BSP itself already contains rules
for ensuring that confidentiality transforms applied by the CB
protect the security result fields within PSB 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 as needed
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 horse was too far out
of the gate 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 include appropriate checksums within
the basic format of each block. 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, 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.
Eddy, et al. Expires March 20, 2008 [Page 14]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 PSBs 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 Security 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.
The normal method for handling error detection with security is to
cover the encrypted payload with an outer error-detecting checksum.
Use of a private key without a separate outer error-detecting
checksum prevents determination of the bundle's fidelity by any in-
path forwarding nodes lacking the key. This discourages
interoperability between parties that do not share keys. 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.
Eddy, et al. Expires March 20, 2008 [Page 15]
Internet-Draft Bundle Checksum Ciphersuites September 2007
5. IANA Considerations
This document has no considerations for IANA.
Eddy, et al. Expires March 20, 2008 [Page 16]
Internet-Draft Bundle Checksum Ciphersuites September 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).
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 error-detection capabilities to the Bundle
Protocol within the limitations of the existing pre-established
security framework.
Eddy, et al. Expires March 20, 2008 [Page 17]
Internet-Draft Bundle Checksum Ciphersuites September 2007
7. References
7.1. Normative References
[I-D.irtf-dtnrg-bundle-security]
Symington, S., "Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-03 (work in progress),
April 2007.
[I-D.irtf-dtnrg-bundle-spec]
Scott, K. and S. Burleigh, "Bundle Protocol
Specification", draft-irtf-dtnrg-bundle-spec-10 (work in
progress), July 2007.
[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.
7.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., "Licklider Transmission Protocol -
Extensions", draft-irtf-dtnrg-ltp-extensions-05 (work in
progress), April 2007.
[I-D.irtf-dtnrg-sec-overview]
Farrell, S., "Delay-Tolerant Networking Security
Overview", draft-irtf-dtnrg-sec-overview-03 (work in
progress), July 2007.
[I-D.irtf-dtnrg-tcp-clayer]
Eddy, et al. Expires March 20, 2008 [Page 18]
Internet-Draft Bundle Checksum Ciphersuites September 2007
Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
Convergence Layer Protocol",
draft-irtf-dtnrg-tcp-clayer-00 (work in progress),
July 2007.
[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.
[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, et al. Expires March 20, 2008 [Page 19]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 proceedure 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 PSB 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 PSB 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
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.
Eddy, et al. Expires March 20, 2008 [Page 20]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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
PSBs.
A.2. PSB Format
PSBs 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 PSBs. Some of the processing rules for
PSBs that make the PSB less than ideal for error-detection purposes
include:
1. If a CB is placed into a bundle that already has a PSB, then
another CB is created that hides the PSB. This means that for
end-to-end error-detection PSBs, any in-network security proxies
that add CB blocks also prevent the checksum in the PSB from
being verifiable before the CB's security destination recovers
the cleartext PSB. If the CB 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
Eddy, et al. Expires March 20, 2008 [Page 21]
Internet-Draft Bundle Checksum Ciphersuites September 2007
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 PSB's security result cannot be retained
outside a CB 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 PSB ciphersuite checksums after generating CBs
that encrypt the payload, so that the PSB security result covers
the CB's encrypted form of the payload rather than the
unencrypted form, and uses the same security destination as the
CB. Upon reaching this security destination, another PSB
destined for the receiver, covering the payload revealed at the
security destination, could be generated. Requiring this would
allow detection of errored bundles between CB security source and
CB security destination, but would involve adding another
instruction to the CB generation process within the BSP. This
assumes no errors are introduced during the decryption process of
the CB, 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 PSB
and CB interaction that doesn't involve layering multiple PSBs that
can be pushed and popped off of a bundle at various security sources
and destinations. 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 March 20, 2008 [Page 22]
Internet-Draft Bundle Checksum Ciphersuites September 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 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 March 20, 2008 [Page 23]
Internet-Draft Bundle Checksum Ciphersuites September 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, et al. Expires March 20, 2008 [Page 24]
