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