idnits 2.17.1 draft-irtf-dtnrg-bundle-checksum-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2009) is 5455 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-08 ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft Verizon 4 Intended status: Experimental L. Wood 5 Expires: November 13, 2009 Cisco Systems 6 W. Ivancic 7 NASA 8 May 12, 2009 10 Reliability-only Ciphersuites for the Bundle Protocol 11 draft-irtf-dtnrg-bundle-checksum-05 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 13, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The Delay-Tolerant Networking Bundle Protocol includes a custody 50 transfer mechanism to provide acknowledgements of receipt for 51 particular bundles. No checksum is included in the basic DTN Bundle 52 Protocol, however, so at intermediate hops, it is not possible to 53 verify that bundles have been either forwarded or passed through 54 convergence layers without error. Without assurance that a bundle 55 has been received without errors, the custody transfer receipt cannot 56 guarantee that a correct copy of the bundle has been transferred, and 57 errored bundles are forwarded when the destination cannot use the 58 errored content, and discarding the errored bundle early would have 59 been better for performance and throughput reasons. This document 60 addresses that situation by defining new ciphersuites for use within 61 the existing Bundle Security Protocol's Payload Integrity Block 62 (formerly called the Payload Security Block [ED: remove old name 63 before RFC]) to provide error-detection functions that do not require 64 support for other, more complex, security-providing ciphersuites that 65 protect integrity against deliberate modifications. This creates the 66 checksum service needed for error-free reliability, and does so by 67 separating security concerns from the few new reliability-only 68 ciphersuite definitions that are introduced here. The reliability- 69 only ciphersuites given here are intended to protect only against 70 errors and accidental modification; not against deliberate integrity 71 violations. This document discusses the advantages and disadvantages 72 of this approach and the existing constraints that combined to drive 73 this design. 75 Table of Contents 77 1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Overview of Header and Payload Integrity . . . . . . . . . 5 79 2. Use of the Payload Integrity Block . . . . . . . . . . . . . . 8 80 2.1. Differences from Intended Use of the Payload Integrity 81 Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3. INSECURE Ciphersuites . . . . . . . . . . . . . . . . . . . . 12 83 3.1. Generation and Processing Rules . . . . . . . . . . . . . 14 84 4. Performance Considerations . . . . . . . . . . . . . . . . . . 15 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Appendix A. Mandatory BSP Elements Needed to Implement 92 Error-Detection . . . . . . . . . . . . . . . . . . . 20 93 A.1. Discussion of Mutable Canonicalization . . . . . . . . . . 20 94 A.2. Discussion of the PIB Format . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Motivations 99 Reliable transmission of information is a well-known problem for all 100 protocol layers. Error-detection and correction capabilities are 101 frequently found in lower layers, but are also present in many 102 higher-layer protocols in order to detect residual bit errors and 103 bugs that introduce errors. For example, IPv4 verifies a simple 104 header checksum when processing packets, even when running over a 105 data link, such as Ethernet, that already performs a stronger CRC. 106 The TCP and UDP transport protocols further include a checksum 107 covering their payloads as well as some IP header fields. This 108 checksum is verified before the data is passed to the application. 109 What may seem like paranoia is actually not unfounded, as errors in 110 received data or packet corruption are known to creep into networking 111 systems from many causes other than channel noise [SP00]. Although 112 coding of data on the channel can reduce the impact of channel noise, 113 and Cylic Redundancy Codes (CRCs) across each link in a network path 114 can catch many channel-induced errors, end-to-end checksums across 115 the entire network path are understood to be necessary for 116 applications requiring certainty that the data received is error-free 117 [SGHP98]. 119 The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838] 120 is founded on an overlay of Bundle Agents (BAs). These Bundle Agents 121 forward data units called bundles via the Bundle Protocol [RFC5050]. 122 Bundles may be lost or errored both during transmission between BAs, 123 or within a BA itself. Bundles belonging to applications that are 124 not tolerant of lost data have a "custody transfer" flag that 125 requests reliable transmission between bundle agents. The notion of 126 reliability used in the basic custody transfer mechanism means that 127 the Bundle Protocol itself not take the integrity of bundles into 128 account, but acknowledges a bundle's receipt and transfers its 129 custody without verifying its internal data integrity. In this way, 130 the bundle protocol provides what has been called a "better than 131 best-effort" service, which attempts through persistence to provide 132 delivery of content without making claims about the end-to-end 133 integrity of that content. Although [RFC4838] discusses 'reliable 134 delivery', this is expected to be provided to the bundle layer, and 135 is not a property of the bundle layer. The "convergence layer 136 adapters" that connect BAs to each other may or may not detect and 137 correct errors before presenting bundle data to the BAs themselves. 138 Convergence layer error detection and correction may be adequate in 139 many cases, but is not always adequate, and the lack of adequacy is 140 recognised in the well-known end-to-end principle [SRC84]. It is 141 possible (and even statistically likely) that either transmission 142 errors will go unnoticed, or unchecked errors will be introduced 143 within a BA's memory, storage, or forwarding systems. Here, each 144 convergence-layer check is analogous to a data-link check, covering a 145 single hop between Bundle Agents, but not the entire network path 146 between source and destination for the bundle. 148 Within the context of DTN, even stronger convergence-layer adapter 149 error detection is not sufficient. Errors within a BA's device 150 drivers, errors due to memory issues within the BA's host, e.g. 151 radiation-induced soft errors, and errors introduced from file-system 152 corruption cannot be detected by convergence layer adapters, as these 153 errors occur in gaps between successive phases of forwarding and 154 convergence-layer processing. In order to ensure integrity of DTN 155 bundles forwarded across a system composed of BAs and convergence 156 layer adapters, end-to-end computation and verification of checksums 157 is required [SRC84]. To detect errors introduced in storage, a 158 checksum across the bundle could be verified before the bundle is 159 sent to the next hop. Detecting errors as early as possible leads to 160 performance increases and better network utiization due to the nature 161 of control loop in DTNs, as described later. 163 Within this document, we describe a use of the Bundle Security 164 Protocol (BSP) [I-D.irtf-dtnrg-bundle-security] in order to provide 165 the desired error-detection service by defining suitable BSP 166 ciphersuites. The design decisions for doing this are explained in 167 Section 2. It should be clearly understood by readers, implementers, 168 and users that we are not using the BSP in a way that provides any 169 level of security, which we explain fully in Section 2.1. The 170 guarantee that we attempt to provide is that specific blocks within a 171 received bundle are highly likely to have been propagated across the 172 overlay without errors, under the assumptions of no malicious 173 activity within or between Bundle Agents and no capability to inject 174 forged bundles. The actual format and use of this error-detection 175 mechanism based on the BSP and requirements for support are described 176 in Section 3. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119. [RFC2119] 182 1.1. Overview of Header and Payload Integrity 184 It is worthwhile to review checksum use in the Internet that ensures 185 error-free delivery, as this should provide a familiar starting point 186 for the reader. This can then be used as a basis for thinking about 187 error-free delivery of bundles. We must distinguish between the need 188 to verify the integrity and reliability of ("protect") carried 189 payloads, and the need to verify the reliability of the protocol 190 carrying the payload - i.e. the need to also protect the header 191 metadata surrounding the payload that the protocol tells itself. 193 Within the topic of payload reliability, applications have differing 194 requirements. Some applications are capable of dealing with errored 195 content, and desire the delivery of any sent content blocks, even if 196 they are not entirely the same content blocks that were originally 197 transmitted. For instance, some voice and video codecs degrade 198 perceptibly under loss of content, but cope well with low levels of 199 error within delivered content. To date, however, most Internet 200 applications have not been tolerant of errored content - and carrying 201 errored content from a noisy physical channel to the application 202 requires that all underlying layers in use at the time pass through 203 and accept errors in their payload data, while simultaneously 204 protecting against and rejecting errors in their own header data. 206 In IPv4, header and payload reliability are implemented separately, 207 with the IPv4 header checksum covering the header information, while 208 the TCP or UDP checksum covers the payload. The TCP/UDP checksum 209 also covers certain important IP header fields - this is the 'pseudo- 210 header' check. In IPv6, the header checksum was removed, to speed up 211 router processing as header fields were changed. The 'pseudo-header' 212 checksum of important IPv6 header fields is still there as part of 213 the overall payload checksum implemented by TCP, UDP, and other 214 protocols. This upper-layer pseudo-header checksum combines the 215 header and payload checks efficiently at the receiving IPv6 endhost 216 to prevent misdelivery of packets and protect against corrupted 217 payloads. This checksum is a final end-to-end check across the 218 entire IP delivery path - for both header and payload. It ensures 219 that the payload has been delivered to the right place, without 220 corruption being introduced. 222 The TCP and UDP checksum mechanism is frequently criticised for being 223 weak in that there are classes of errors it does not detect. This 224 checksum is computed by summing 16-bit values within a packet. If 225 two strings are swapped in position within the packet, the checksum 226 can remain unchanged even though the datagram is now different from 227 the original, and clearly corrupted. The UDP convergence-layer 228 adapter that has been popularly implemented in DTN stacks relies on 229 UDP's usual 16-bit one's-complement checksum (the same algorithm used 230 for IPv4 headers and TCP segments) to validate incoming datagrams. 231 The proposed TCP-based convergence layer [I-D.irtf-dtnrg-tcp-clayer] 232 relies on the same checksum algorithm. This checksum algorithm is 233 remarkably useful in its position covering an entire network path and 234 ability to detect all errors introduced, even though its overall 235 strength against errors is considered weak, and in more recent 236 transport protocols has been reconsidered; for instance, SCTP uses 237 the CRC-32c algorithm instead [RFC3309]. It is the ability to 238 provide a check that the packet at the destination is the same at the 239 source that is most useful for Internet traffic; the overall check 240 mechanism strength is secondary to this. Any check is better than 241 none. The UDP- and TCP-convergence layers and their checksums are 242 only useful for one 'bundle hop' between peer agents across the 243 Internet, and will not cover multiple bundle hops as an end-to-end 244 checksum. 246 In absence of IP packet fragmentation, it would be possible for all 247 intermediate routers in the terrestrial Internet to verify the upper- 248 layer pseudo-header checksum at each hop rather than just checking 249 data-link CRCs, but this is not normally done, as it would be 250 burdensome to busy routers as well as a philosophical "layer 251 violation". (Network Address Translation, where the change in 252 pseudo-header addresses affects the checksum value, is an exception 253 to this.) Not checking the payload at every hop takes advantage of 254 the closed-loop nature of fast Internet communication; the cost of 255 packet delivery is cheap, so necessary protection against corrupted 256 packets or headers need only be done at the last possible moment with 257 a check at the endhost, as the costs incurred in delivering the 258 packet to that node, and any resent packets to that node, are 259 minuscule. It is the cheap cost of resending and the tight end-to- 260 end control loop which can permit reliability checks to be pushed up 261 to or only done at the application layer, in accordance with the end- 262 to-end principle, without adversely affecting overall communication 263 efficiency. 265 In challenged delay-tolerant networks, the network capacity, 266 forwarding and storage costs for bundles are far higher, as are the 267 costs of getting a resent bundle. This produces a longer, slower, 268 control loop and alters the cost/benefit tradeoff. It becomes 269 worthwhile for intermediate bundle nodes to check non-error-tolerant 270 content, which includes important header fields and metadata, for 271 error-free correctness before forwarding it, to prevent incurring 272 unnecessary transmission costs and to also increase the possibility 273 of getting the bundle from the source or from over the previous hop 274 again if it needs to be resent, shortening the overall resend time. 275 Due to the more open-loop nature of communication across delay- 276 tolerant and disrupted networks, applications do not communicate as 277 well or as easily as they do in the traditional Internet, meaning 278 that the efficiency tradeoff for application-only checks is such that 279 non-error-tolerant DTN application performance can be expected to 280 increase with earlier detection of errors and earlier resends within 281 the network. Network costs are decreased and utilization is 282 increased by early discard of known 'bad' traffic. This is a concern 283 that has previously led to e.g. ATM Early Packet Discard (EPD). 285 This shift in costs caused by the difficulty of resending 286 information, when compared to the traditional Internet, makes 287 verifying the correctness of the header and non-error-tolerant 288 payload content at each bundle node considerably more important, to 289 permit faster resends and conserve storage and transmission capacity. 290 The Bundle Protocol, as specified in [RFC5050], does neither of these 291 things. Nor does the Bundle Protocol protect itself end-to-end. 292 There is no Bundle Protocol check on header or payload at destination 293 bundle nodes; there is no end-to-end equivalent to the two checks 294 that the TCP/UDP checksum so neatly combines and provides for 295 Internet traffic. There is a need for a check at intermediate nodes 296 in challenged networks for suitable traffic, given the cost tradeoffs 297 outlined above, yet those nodes cannot take advantage of a 298 precomputed end-to-end checksum unless one is first provided for 299 them. 301 This document lays out a way to redress this lack of robustness in 302 the existing Bundle Protocol in Section 3, and carefully describes 303 the drawbacks to this method in Section 4 and Section 5. 305 2. Use of the Payload Integrity Block 307 The BSP defines three types of blocks: 309 o the Bundle Authentication Block (BAB), 311 o the Payload Integrity Block (PIB), 313 o the Payload Confidentiality Block (PCB). 315 Algorithms applied within each of these blocks could be reused to 316 detect errors introduced in bundle contents. However, based on the 317 different design goals motivating these three block types, the PIB is 318 the only candidate that is truly suitable for supporting the type of 319 checksum fields needed to yield end-to-end reliability of received 320 bundles. 322 The BAB is intended to operate along a single hop within a DTN 323 overlay network, and due to the issues discussed in the previous 324 section, even an end-to-end chain of hops using the BAB over each hop 325 is not sufficient for ensuring reliability. 327 The PCB is primarily concerned with the operation of privacy 328 transforms over a bundle's contents, which are intended to 329 significantly alter and disguise the protected data while in transit, 330 rather than simply performing consistency checks over untransformed 331 data. 333 The PIB is intended to be used end-to-end; that is, by a set of 334 endpoints, rather than hop-by-hop at each intermediate point. The 335 PIB is intended to be used with sets of cryptographic algorithms 336 (ciphersuites) that provide Message Authentication Codes (MACs) or 337 signatures over bundle or block contents. MAC and signature 338 algorithms are security constructions that may allow verification of 339 a legitimate sender (authentication), detection of in-transit 340 tampering (integrity), and proof of a particular sender (non- 341 repudiation with proof of origin). As a consequence of the integrity 342 goal, which is based on the assumption of an adversary that can alter 343 messages in-flight, MACs and signatures can also be effective at 344 detecting errors that occur without the presence of an attacker and 345 in the absence of any malicious intent, e.g. due to bit errors within 346 transmission media, file system corruption, etc. Since the PIB uses 347 the BSP's mutable canonicalization and covers the Primary Bundle 348 Block, the EIDs and other data influencing forwarding and delivery of 349 payloads are also protected by the MACs or signatures in addition to 350 the payload data. 352 The error-detecting and rejecting capabilities of a MAC or signature 353 are similar to those of more-simple checksum algorithms that are 354 intended only for error-detection. In fact, several popular MAC and 355 signature constructions use checksums as primary components. For 356 instance, the MD5 digest (hash) algorithm [RFC1321] is used within 357 the HMAC-MD5 keyed-hash MAC construction [RFC2104]. Computationally, 358 for large messages, the efficiency of a security construction 359 providing integrity is similar to that of a simple checksum, although 360 for short messages, it may be much worse. For instance, HMAC 361 requires multiple applications of the underlying hash function, with 362 the final one being over a very short input, but if the message 363 itself fits within a single block, this results in twice the overhead 364 compared to a simple checksum. Thus, assuming large bundles in 365 relation to the block size of typical hash functions, the PIB can 366 provide end-to-end error-detection capability for bundles from the 367 standpoints of both reasonable effectiveness and reasonable 368 computational cost. 370 2.1. Differences from Intended Use of the Payload Integrity Block 372 The main difference between any simple error-detecting checksum and a 373 security construction designed for integrity is that the security 374 construction requires keying material. Key management is recognized 375 as an outstanding unsolved problem within the DTNRG 376 [I-D.irtf-dtnrg-sec-overview] [WEH09] and is thought to be quite 377 difficult. Key management in well-connected systems, such as the 378 Internet, is difficult itself, without the additional complications 379 of a DTN networking environment. However, if using a keyed security 380 construction for simple error-detection, the secrecy of the key is 381 unimportant, and a feasible approach is to specify a hard-coded key 382 that all nodes use in the error-detection mechanism. The NULL 383 ciphersuite used in the Licklider Transmission Protocol (LTP) for its 384 authentication extension is one example of this [RFC5327]) that led 385 directly to this approach. Using this approach, existing keyed 386 ciphersuites defined for the PIB could be used with well-known keys 387 to provide an error-detection mechanism, without requiring a key 388 management mechanism. However, this key-based method reuses a 389 security mechanism for error detection, for which it is not intended, 390 and requires implementing a seucity algorithm more complex and 391 processor-intensive than the minimal CRC32c approach discussed here. 392 As the Bundle Protocol has no separate outer error detection covering 393 this security payload, if a secret key is used, then third-party 394 intermediate nodes that do not know that secret key cannot determine 395 the reliability of the content, and would be unable to prevent 396 unnecessary forwarding of errored bundles belonging to non-error- 397 tolerant applications. This may lead to decreased performance of the 398 network due to utilization of storage, bandwidth, and power for 399 unusable bundles, and poor end-to-end performance due to the open 400 nature of its control loop as discussed above. 402 If early detection and discard of unusable bundles is done to prevent 403 errors, this gives unencrypted bundle delivery a network performance 404 advantage over secure bundle delivery using secret keys. 405 Applications wanting both security and network performance would gain 406 both by implementing their own end-to-end security within unencrypted 407 bundles using the insecure ciphersuites defined in this document, or 408 by applying a reliability ciphersuite after applying a security 409 ciphersuite. 411 The only PIB ciphersuite included in the BSP to date is PIB-RSA- 412 SHA256, which creates and verifies signatures of bundles using RSA 413 asymmetric-key operations over a SHA-256 hash of the bundle. The 414 length of the SHA-256 output (32 octets) can be considered too large 415 an overhead for providing simple error-detection on all but extremely 416 large bundles. The processing overhead of SHA-256 and RSA 417 calculations also discourages adopting these on computationally- 418 constrained embedded systems. But the biggest problem with PIB-RSA- 419 SHA256 is the bulk of code needed to support the RSA operations, 420 which include math on numbers larger than that supported by common 421 processors' native instruction sets and modular arithmetic libraries. 422 Since error-detection and rejection is a vital and absolutely 423 essential component of reliable networking protocols, and much of the 424 purpose of the DTN architecture is to enable internetworking of 425 devices with limited resources, e.g. motes, it would be burdensome on 426 limited low-end embedded systems to require all Bundle Protocol 427 implementations to include RSA code. 429 The BAB-HMAC ciphersuite that uses SHA1 [RFC3174] within the HMAC 430 construction (HMAC-SHA1) has been specified as mandatory for BSP 431 support. Even though the BAB is not appropriate for end-to-end 432 error-detection, it is certain that BSP implementations will include 433 HMAC-SHA1 routines, and that creating another ciphersuite for PIB- 434 HMAC (which does not exist in the base BSP specification) would 435 impose very little additional code. Partial support for the BSP's 436 elements (at least the PIB's format and mutable canonicalization) 437 could be made mandatory in a future revision of the Bundle Protocol 438 along with support for the PIB-HMAC ciphersuite with NULL keys while 439 retaining as optional all of the other components of the BSP (BAB, 440 PCB, and other ciphersuites). Such a path seems to be desirable in 441 that it allows re-use of existing code along with re-use of existing 442 specifications, but does not significantly burden lightweight 443 implementations or deployments unconcerned with overlay-layer 444 security. This approach is followed in Section 3 within this 445 document. 447 There are disadvantages to reusing the existing Bundle Security 448 Protocol for reliability-only purposes. Some deployments on limited 449 hardware within closed networks will not desire to run heavyweight 450 security protocols, nor include the full BSP and its mandatory 451 ciphersuites within their code footprints, decreasing 452 interoperability and adoption of the BSP. There is a desire to avoid 453 creating a false sense of security by using a mechanism labelled the 454 Bundle _Security_ Protocol with either a ciphersuite or NULL key that 455 provides absolutely no security services. For instance, if an 456 implementation allowed this to be configured using the same 457 mechanisms or policy directive configuration files, formats, etc. 458 that are normally used to configure BSP mechanisms providing real 459 security, then a misconfiguration or misunderstanding could have a 460 negative security impact to an operational system. 462 In order to allay these concerns, it was decided to define simple 463 error-detection ciphersuites with the string "INSECURE" in their 464 mnemonics and draw a line as to which portions of the BSP security 465 framework become mandatory and which remain optional. This allows 466 implementation of error-detection capabilities either with or without 467 the majority of the BSP, and with reduced potential for misleading 468 users with regards to security. 470 Implementations that provide both the full BSP and simple error- 471 detection ciphersuites SHOULD ensure that their configuration by 472 users is sufficiently dissimilar from the normal BSP configuration. 473 Implementations MUST NOT implement the "INSECURE" ciphersuites in 474 such a way that leads to their being construed as security 475 mechanisms, e.g. in logging output or configuration directives. 477 3. INSECURE Ciphersuites 479 Any PIB ciphersuite providing only integrity checking for error- 480 detection and using published (or "null") keys MUST contain the 481 string "INSECURE" in its mnemonic. PIBs that use these ciphersuites 482 are otherwise indistinguishable from PIBs used to implement security 483 services. PIB-HMAC is keyed, and so does not use "INSECURE" in its 484 name. When used with a secret key, PIB-HMAC is useful for security, 485 although this is not the case when it is used with a NULL key, we 486 assume that the presence of a NULL key in the configuration 487 significantly alerts users to the fact that it is not providing 488 security. 490 To provide the desired functionality, three new ciphersuites are 491 defined in this document (PIB-HMAC used with either real or NULL 492 keys, PIB-INSECURE-MD5, and PIB-INSECURE-CRC32). The motivations 493 behind defining all three of these ciphersuites are outlined below in 494 the more detailed description of each ciphersuite. All of the 495 ciphersuites defined here use the mutable canonicalization algorithm 496 that is defined in the BSP and compute their checksums over the 497 canonical forms of bundles. If error-detection support is considered 498 essential for use of the bundle protocol, this means that the minimal 499 BSP elements that all Bundle Protocol implementations MUST support 500 include: 502 1. Mutable Canonicalization - discussed in Appendix A.1 of this 503 document. 505 2. PIB wire-format - discussed in Appendix A.2 of this document. 507 3. PIB-HMAC ciphersuite with NULL key definition, PIB-INSECURE-MD5 508 and PIB-INSECURE-CRC32 ciphersuite 510 The new ciphersuites are identified by the following ciphersuite IDs 511 within the abstract security block: 513 o 0x04 - PIB-HMAC 515 o 0x05 - PIB-INSECURE-MD5 517 o 0x06 - PIB-INSECURE-CRC32 519 PIB-HMAC is defined to use the same HMAC-SHA1 construction as the 520 BSP's BAB-HMAC ciphersuite, and can thus leverage existing code. 521 Three ciphersuite parameters are needed, all of which are SDNVs. The 522 first SDNV is a key identifier. A zero value in the key identifier 523 field of a PIB using the PIB-HMAC ciphersuite indicates that the 524 algorithm is keyed with the special NULL key. The NULL key used here 525 is defined to be 0xc37b 7e64 9258 4340 bed1 2207 8089 4115 5068 f738, 526 the same fixed NULL key used with LTP's NULL ciphersuite. The later 527 two SDNVs are offsets describing the protected bits of the bundle, 528 identical to the offset and length parameters describe in the BSP's 529 PIB-RSA-SHA256 ciphersuite. The first identifies the first covered 530 octet and the second identifies the last covered octet. 532 PIB-HMAC creates a ten-octet security result and should provide 533 adequate error-detection capabilities for large bundles of at least 534 several gigabytes in size. Its advantage lies in that the NULL-keyed 535 version can be implemented with minor additions to existing BSP 536 codebases, and support for HMAC-SHA1 is known to only require around 537 two hundred lines of portable C code for implementations that do not 538 already contain BSP support. 540 The existence of the PIB-INSECURE-MD5 ciphersuite is motivated by the 541 fact that an MD5 hash can be computed on the order of twice as fast 542 as a SHA1 hash over the same data, as demonstrated by benchmarking 543 activities [RFC1810], yet still yields robust error-detection over 544 fairly large inputs. This may be desirable in environments that have 545 only limited computational resources to expend on bundle generation 546 or processing. For instance, the authors have implemented generation 547 of bundles of up to several hundred megabytes in size, onboard an 548 imaging satellite solid-state data recorder using only a 200 MHz 549 processor. The PIB-INSECURE-MD5 parameters consist of two SDNVs, an 550 offset and length, that convey the covered portion of the bundle, in 551 an identical way to the corresponding PIB-HMAC and PIB-RSA-SHA256 552 parameters. 554 The security result included with the PIB-INSECURE-MD5 ciphersuite is 555 a full 16-octet MD5 output. The longer security result than PIB-HMAC 556 may provide better error-detection for very large bundles, in 557 addition to being faster to compute. For small bundles, the lack of 558 the HMAC construction's second application of the hash function also 559 improves efficiency in PIB-INSECURE-MD5 compared to PIB-HMAC. 560 Implementations of MD5 are known to require only around 200 lines of 561 portable C code and are widely available as open-source and within 562 the MD5 RFC [RFC1321]. 564 The PIB-INSECURE-CRC32 ciphersuite is intended for small bundles, and 565 SHOULD only be used on bundles whose payload length is less than 566 65535 bits, because its protection weakens for longer payloads due to 567 the increased risk of collisions [Koop02]. The parameters included 568 with this ciphersuite are identical to those used with PIB-INSECURE- 569 MD5. The security result is computed using the CRC-32c algorithm, 570 identically to that defined for use with SCTP [RFC3309]. The 571 security result is always a 4-octet quantity when PIB-INSECURE-CRC32 572 is used. The advantage of the CRC used as a checksum in this 573 ciphersuite is that it implies a lower header overhead to in-flight 574 or in-memory bundles with small payloads, in comparison to the length 575 of the PIB-HMAC and PIB-INSECURE-MD5 results. This may be highly 576 desirable in environments where small messaging bundles are normal 577 and only bandwidth-limited links are available. The CRC-32c 578 algorithm is known to be implementable in only a few dozen lines of 579 portable C code. 581 3.1. Generation and Processing Rules 583 Since the INSECURE ciphersuites and NULL-keyed PIB-HMAC use the same 584 block type code and format as the more secure uses of PIB, they 585 inherit the existing generation and processing rules of the PIB. 586 This is good from a security standpoint in two respects: 588 1. The existing PIB processing rules consider interaction with any 589 BABs that might be added to a bundle and prevent interactions 590 that would cause wrongful failure of MACs, signatures, and 591 checksums. 593 2. The PIB and PCB processing rules remove the possibility of a MAC, 594 signature, or checksum revealing information about the private 595 contents of the PCB via the ordering of the applied security/ 596 error-detection transforms. This is discussed within the PCB- 597 RSA-AES128-PAYLOAD-PIB ciphersuite definition in the BSP 598 specification. 600 Although the BSP was intended as an optional suite of extensions to 601 the Bundle Protocol, and only needed in cases where certain security 602 services are desired at the bundle layer, a subset of its components 603 is now required to implement the PIB-based error-detection mechanism. 604 As (1) providing error detection at some place in the stack is needed 605 by applications that require reliable delivery of payload content, 606 (2) many conceivable applications require such delivery, and (3) the 607 Bundle Protocol is a proposed new stack "waist in the hourglass", 608 error detection is clearly very desirable in common implementations 609 of the Bundle Protocol. Supporting error-free delivery does not 610 require mandatory implementation of the full BSP and accompanying 611 security ciphersuites, but only requires the PIB block format, and 612 the mutable canonicalization rules. These two portions of the BSP 613 are fully described in the BSP specification 614 [I-D.irtf-dtnrg-bundle-security] with some commentary regarding their 615 use for error-detection in Appendix A of this document. 617 When non-error-tolerant applications request custody transfer, it is 618 extremely desirable to use an unkeyed or NULL-keyed PIB ciphersuite 619 defined in this document between the source and destination bundle 620 agents, to ensure that the custodian now has a correct copy of the 621 bundle. Use of ciphersuites with secret keys shared only by end- 622 hosts cannot assist in reliable hop-by-hop delivery, increasing the 623 time to error detection at the end nodes and the time required for 624 resends. For other bundles, not requiring custody transfer, an 625 unkeyed or NULL-keyed PIB ciphersuite SHOULD be used. 627 Checking of unkeyed or NULL-keyed PIBs at intermediate bundle agents 628 SHOULD be performed, when possible, and an agent which fails to match 629 the PIB security result within a bundle SHOULD immediately discard 630 the bundle. This limits the wasted resources involved in propagating 631 data now known to be errored. It is desirable that PIB hashes or 632 checksums are recalculated whenever fragmented bundles are 633 reassembled, to ensure that no damage was introduced by the 634 fragmentation process. A future version of the Bundle Protocol might 635 include a bundle processing flag that signals that errored-delivery 636 is acceptable to a receiving application. However, the current 637 version does not define such a flag. A future version of the Bundle 638 Protocol specification might also define an administrative record 639 that signals when a bundle has been dropped due to a corruption event 640 detected via an unkeyed or NULL-keyed PIB check; that has not been 641 defined in the current Bundle Protocol. The IRTF Delay-Tolerant 642 Networking Research Group (DTNRG) has not achieved consensus on 643 either of these possibilities at time of writing. 645 4. Performance Considerations 647 The normal method for handling error detection with security is to 648 cover the encrypted payload with an outer error-detecting checksum 649 wrapper. Use of an end-to-end secret key without a separate end-to- 650 end outer error-detecting checksum prevents determination of the 651 bundle's fidelity by any in-path forwarding nodes lacking that secret 652 key. This discourages interoperability between parties that do not 653 share keys, and consumes more network resources in relaying an 654 errored bundle to the receiving destination end node, and in 655 resending the bundle across its entire path once the error is finally 656 detected at the destination on decryption. Custody transfer 657 guaranteeing error-free receipt at intermediate nodes is not possible 658 with secret keys in the mechanism outlined above. When secret keys 659 are in use, errors introduced into bundles can only be detected at 660 the decoding endpoint, rather than at intermediate nodes, meaning 661 that resends across the entire network are requested far later when 662 security is in use. This means that applications using unencrypted 663 traffic can be expected to outperform applications using secret keys 664 in DTN networks, thanks to their ability to detect errors earlier, 665 their smaller resend control loops to get replacement bundles, and 666 adding the capability for content verification to the use of custody 667 transfer. 669 Again, an outer error-detecting checksum around the encrypted or 670 unencrypted bundle prevents these problems, and allows custody 671 transfer to be meaningful and indicate truly reliable receipt even 672 for encrypted traffic where the encryption keys are not known by the 673 custody agent. Having an error-detecting checksum cover a previously 674 encrypted block allows the reliability of that block to be checked at 675 intermediate nodes without requiring decryption key, leading to 676 earlier detection of errors and earlier resends. This enables the 677 intermediate network to help with increasing the throughput and 678 performance of the applications at the end nodes. A worked example 679 of this is given in [WEH09]. 681 When secret keys are used for security, a second reliability-only 682 insecure ciphersuite SHOULD be used across the encrypted payloads, to 683 allow verification of correct delivery at intermediate nodes, to 684 allow custody transfer to indicate reliable receipt of the encrypted 685 content, and to increase the forwarding performance and efficiency of 686 the overall network. 688 5. Security Considerations 690 This document has attempted to assuage any security concerns that 691 would result from applying non-security-providing algorithms within a 692 mechanism intended for security. This is accomplished through 693 semantic overloading of the PIB, reusing its structure to hold a 694 simple checksum when it is not intended to provide security services. 696 The potential leakage of information if checksums are not covered by 697 some BSP confidentiality transform that is applied later in the 698 transmission path is eliminated by the fact that the existing PIB 699 block type code is used, and the BSP itself already contains rules 700 for ensuring that confidentiality transforms applied by the PCB 701 protect the security result fields within PIB instances. 703 This design decision to reuse a security block for error-detection 704 may seem bizarre to both security and networking experts. However, 705 this decision was necessitated by the late addition of checksum 706 support to the Bundle Protocol. By the time interest in this subject 707 arose within the DTNRG, the Bundle Protocol itself was in final 708 review phases and had been implemented multiple times. When we began 709 this work, the group did not have consensus that block validation and 710 payload error detection even belonged in the Bundle Protocol itself. 711 The Bundle Security Protocol was also no longer malleable enough to 712 ensure compatibility with checksum support, as it had obtained a 713 level of relative stability in its specification and there were 714 existing implementation efforts based on these which could have 715 required modification in order to not pass checksums carried in a 716 non-BSP block as unprotected after performing a confidentiality 717 transform of the payload. 719 In the authors' opinion, ideally, the error-detection functions would 720 be implemented within the basic networking portions of the Bundle 721 Protocol, and not as a subset of the security framework. However, 722 the existing Bundle Protocol design was too well-established for the 723 current definition of the Bundle Protocol to be affected. At this 724 time, the Bundle Protocol has only been proposed as Experimental with 725 some disclaimers. It is felt by some that future revisions of the 726 Bundle Protocol need to provide mechanisms ensuring error detection 727 for reliable delivery. In order to limit overhead, shorter 728 checksums, e.g. CRC-16, could be used for small blocks, with longer 729 checksums, e.g. MD5, reserved for large payload blocks. This would 730 allow checksums to cover and provide confident processing of even 731 blocks with mutable fields, and retain efficient updating in-network 732 as a mutable field changes, without the recomputation also covering 733 large unchanging payload blocks. This might also constrain the 734 damage caused by errors to the functions provided by an individual 735 block, rather than affecting the whole bundle and causing the whole 736 bundle to be discarded, although the overall value of this is 737 currently unknown. 739 The need to conserve limited network resources by detecting and 740 avoiding further propagating errored bundles in-transit means that 741 Bundle Agents SHOULD always validate checksums of in-flight bundles, 742 even if the Agents are not the ultimate destination. This opens the 743 door for a potential denial-of-service attack on DTN Bundle Agents by 744 forcing them to expend computational cycles on bundles with large 745 payloads. In this case, the attacker would also have to send these 746 bundles over some link towards the target Bundle Agent, which will 747 often be more constrained in bandwidth or availability than the 748 Bundle Agent is in computational cycles, so this threat may be 749 unrealistic, or better combatted through access-control on links. If 750 this threat does turn out to be realistic in some set of 751 circumstances, intermediary validation of PIBs was intentionally left 752 as a SHOULD-level activity rather than a MUST, and could be 753 dynamically disabled at some threshold of CPU use. 755 Using the same protocol mechanism to provide (1) error-detection 756 without security claims, (2) error-detection using a security 757 protocol insecurely-keyed with a known NULL key, and (3) actual 758 security protection using the same protocol but with secret keys, any 759 of which can defined and used in the same "Payload Integrity Block", 760 is confusing at best, and not a good clean-sheet approach to helping 761 ensure secure configurations, interoperable implementations, or 762 efficient handling of errored bundles. 764 Use of a NULL key is inferior to separately handling the security 765 concerns of sender-authentication and integrity-protection from that 766 of error-checking, as it opens the door to secret keys that prevent 767 standalone error-detection, and should be discouraged. Also, the 768 NULL key cannot provide error-detection needed for the mutable parts 769 of the bundle. Providing any error detection for the mutable parts 770 of the bundle has not been done here, and reliance on the fidelity of 771 mutable fields and payloads should be avoided for this reason. 773 6. IANA Considerations 775 This document has no considerations for IANA. 777 7. Acknowledgements 779 Some of the work on this document was performed at NASA's Glenn 780 Research Center under funding from the Earth Science Technology 781 Office (ESTO) and the Space Communications Architecture Working Group 782 (SCAWG). 784 Discussion in the DTNRG and particular suggestions from 785 (alphabetically) Mike Demmer, Kevin Fall, Stephen Farrell, Darren 786 Long, Peter Lovell, and Susan Symington guided the genesis of this 787 document and were crucial to adding limited error-detection 788 capabilities to the Bundle Protocol within the existing pre- 789 established security framework. 791 8. References 793 8.1. Normative References 795 [I-D.irtf-dtnrg-bundle-security] 796 Symington, S., Farrell, S., Weiss, H., and P. Lovell, 797 "Bundle Security Protocol Specification", 798 draft-irtf-dtnrg-bundle-security-08 (work in progress), 799 March 2009. 801 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 802 April 1992. 804 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 805 Hashing for Message Authentication", RFC 2104, 806 February 1997. 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 812 (SHA1)", RFC 3174, September 2001. 814 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 815 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 816 September 2002. 818 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 819 Specification", RFC 5050, November 2007. 821 8.2. Informative References 823 [I-D.irtf-dtnrg-sec-overview] 824 Farrell, S., Symington, S., Weiss, H., and P. Lovell, 825 "Delay-Tolerant Networking Security Overview", 826 draft-irtf-dtnrg-sec-overview-06 (work in progress), 827 March 2009. 829 [I-D.irtf-dtnrg-tcp-clayer] 830 Demmer, M. and J. Ott, "Delay Tolerant Networking TCP 831 Convergence Layer Protocol", 832 draft-irtf-dtnrg-tcp-clayer-02 (work in progress), 833 November 2008. 835 [Koop02] Koopman, P., "32-bit cyclic redundancy codes for Internet 836 applications", Proceedings of the International Conference 837 on Dependable Systems and Networks (DSN), pp. 459-468 , 838 June 2002. 840 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 841 September 1981. 843 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 844 RFC 793, September 1981. 846 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 847 July 1994. 849 [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, 850 June 1995. 852 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 853 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 854 Networking Architecture", RFC 4838, April 2007. 856 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 857 Transmission Protocol - Security Extensions", RFC 5327, 858 September 2008. 860 [SGHP98] Stone, J., Greenwald, M., Hughes, J., and C. Partridge, 861 "Performance of checksums and CRCs over real data", IEEE 862 Transactions on Networks vol. 6 issue 5, pp. 529-543, 863 October 1998. 865 [SP00] Stone, J. and C. Partridge, "When the CRC and TCP Checksum 866 Disagree", Proceedings of ACM SIGCOMM , September 2000. 868 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-end Arguments 869 in System Design", ACM Transactions on Computer Systems 2 870 (4), November 1984. 872 [WEH09] Wood, L., Eddy, W., and P. Holliday, "A Bundle of 873 Problems", IEEE Aerospace conference, Big Sky, Montana , 874 March 2009. 876 Appendix A. Mandatory BSP Elements Needed to Implement Error-Detection 878 This document makes some BSP components mandatory to Bundle Protocol 879 implementations, in that while their use is optional they must be 880 supported for interoperability reasons. Previously, the BSP was 881 previously entirely optional, meaning that bundle protocol 882 implementations could have no internal integrity mechanisms. This 883 appendix discusses these elements in greater detail, and highlights 884 some further drawbacks of basing error detection and protocol 885 reliability upon these elements. 887 A.1. Discussion of Mutable Canonicalization 889 Mutable Canonicalisation is defined by the Bundle Security Protocol. 891 While impressively named, the mutable canonicalization procedure 892 should actually be quite simple to understand. The requirement for 893 mutable canonicalization stems from the Bundle Protocol's forwarding 894 design that allows several "mutable" fields (e.g. the "dictionary", 895 custodian, and some flags and length fields), to change in-transit at 896 intermediate nodes. In order for the checksum, MAC, or signature 897 computed and placed in the security result of a sent PIB to match the 898 result computed over the received bundle, the sender and receiver 899 need to leave mutable fields out of these computations. The format 900 of a bundle that is input to the PIB algorithms thus differs from its 901 wire-format, and is called its "mutable canonicalization". 903 Using mutable canonicalization implies either using an incrementally- 904 updatable checksum algorithm and feeding many small pieces of data to 905 it, or entirely rewriting a bundle block-by-block based on mutable 906 canonicalization rules before feeding it to the checksum function. 907 (The mutable fields still require protection against errors; a hop- 908 by-hop checksum over only the mutable fields could be used to provide 909 this. Hop-by-hop checksum coverage could be provided by a 910 convergence layer or BAB, but this would likely cover the entire 911 bundle or fragment.) 913 Several problems are known to plague mutable canonicalization: 915 1. [EDITOR'S NOTE: This concern may be easily fixed in updates to 916 the BSP document.] The Bundle Protocol specification describes 917 the bundle processing control flags as a single variable-length 918 SDNV whose bits are sub-divided in-order by function into "SRR" 919 (Status Report Request), "COS" (Class of Service), and "General". 920 The BSP's mutable canonicalization description shows three 921 separate fields, with only slightly differing names, but in 922 totally opposite order: "Proc. Flags", "COS Flags", and "SRR 923 Flags", instead of one single SDNV, yet has text that describes 924 operating on these as a single 64-bit value and applying a fixed- 925 length mask to them. This is unclear at best, and feared to be 926 uninteroperable in implementations. 928 2. Many bits within the bundle processing control flags are masked 929 out (i.e. forced to zero within) the mutable canonicalization 930 format. This includes all of the reserved class of service (COS) 931 bits that are highly likely to be needed to overcome the 932 limitation of having only three defined priority levels in the 933 Bundle Specification (compare to DiffServ, CLNP's priority field, 934 Aeronautical Mobile Radio Service message priorities, or 935 mechanisms in other networking stacks that provide many more 936 bits). This means that these bits, and any other bundle 937 processing control bits, will be unprotected by the end-to-end 938 checksum and may change in-transit, potentially causing mis- 939 treatment or mal-delivery of bundles. 941 3. The existing "bundle is a fragment" bit is unprotected in mutable 942 canonicalization. Errors in this bit itself can probably be 943 caught through other means, such as careful length and bound 944 checking in processing the rest of the bundle. 946 4. The entire mutable canonicalization procedure of parsing and re- 947 formatting bundles in order to perform a checksum validation is 948 significantly more complex than is typical in most existing 949 protocols that are designed to be capable of simply computing a 950 validation over a frame either without modifications [RFC1662], 951 with only a small fixed-length and position field masked 953 [RFC0791], or with only a simple fixed-size pseudoheader 954 [RFC0793]. The significant additional complexity of mutable 955 canonicalization prevents high performance in forwarding nodes 956 that follow the guideline of verifying unkeyed or NULL-keyed 957 PIBs. 959 A.2. Discussion of the PIB Format 961 The PIB is defined by the Bundle Security Protocol. 963 PIBs follow the format of the abstract security block with a block 964 type code that identifies them as PIBs. Some of the processing rules 965 for PIBs that make the PIB less than ideal for error-detection 966 purposes include: 968 1. If a PCB is placed into a bundle that already has a PSB, then 969 another PCB is created that hides the PIB. This means that for 970 end-to-end error-detection PIBs, any in-network security proxies 971 that add PCB blocks also prevent the checksum in the PIB from 972 being verifiable before the PCB's security destination recovers 973 the cleartext PIB. If the PCB security destination is never 974 reached, the bundle cannot be checked for errors. Errored 975 bundles will consume resources between these two security 976 gateways, since the errors cannot be detected and the bundles 977 discarded en route. The RSA signature of such an errored bundle 978 will only fail at the security destination, and the bundle will 979 only be discarded at that end point, but there may be significant 980 resources expended in delivering the useless bundle to that 981 point. 983 2. A previously-generated PIB's security result cannot be retained 984 outside a PCB in the clear, because an observer could correlate 985 the value to some known probable plaintext payload value. It 986 might be better to reverse the order of operations and always 987 generate rewritten PIB ciphersuite checksums after generating 988 PCBs that encrypt the payload, so that the PIB security result 989 covers the PCB's encrypted form of the payload rather than the 990 unencrypted form, and uses the same security destination as the 991 PCB. Upon reaching this security destination, another PIB 992 destined for the receiver, covering the payload revealed at the 993 security destination, could be generated. Requiring this would 994 allow detection of errored bundles between PCB security source 995 and PCB security destination, but would involve adding another 996 instruction to the PCB generation process within the BSP. This 997 assumes no errors are introduced during the decryption process of 998 the PCB, as such errors would go undetected. If bundles pass 999 through nested security domains, this could compound the error 1000 rate. 1002 There appears to be both benefits and drawbacks to any approach to 1003 PIB and PCB interaction that does not involve layering multiple PIBs 1004 that can be pushed and popped off of a bundle at various security 1005 sources and destinations. Pushing and popping nested PSBs 1006 approximates the outer checksum around inner security payload used 1007 successfully elsewhere in networking. By some reasonable metrics, 1008 the BSP-prescribed interaction that we have attempted to build on and 1009 fix here may be among the least desirable of all known methods for 1010 error detection. 1012 Authors' Addresses 1014 Wesley M. Eddy 1015 Verizon Federal Network Systems 1016 NASA Glenn Research Center 1017 21000 Brookpark Road 1018 Cleveland, Ohio 44135 1019 United States of America 1021 Phone: +1-216-433-6682 1022 Email: weddy@grc.nasa.gov 1024 Lloyd Wood 1025 Cisco Systems 1026 11 New Square Park, Bedfont Lakes 1027 Feltham, Middlesex TW14 8HA 1028 United Kingdom 1030 Phone: +44-20-8824-4236 1031 Email: lwood@cisco.com 1033 Will Ivancic 1034 NASA Glenn Research Center 1035 21000 Brookpark Road 1036 Cleveland, Ohio 44135 1037 United States of America 1039 Phone: +1-216-433-3494 1040 Fax: +1-216-433-8705 1041 Email: William.D.Ivancic@nasa.gov