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