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