idnits 2.17.1 draft-irtf-dtnrg-bundle-checksum-03.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 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1030. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1036. 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 (October 31, 2008) is 5654 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 (-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 (~~), 4 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: May 4, 2009 Cisco Systems 6 W. Ivancic 7 NASA 8 October 31, 2008 10 Checksum Ciphersuites for the Bundle Protocol 11 draft-irtf-dtnrg-bundle-checksum-03 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 May 4, 2009. 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 [RFC5327]). Using this approach, existing keyed ciphersuites 362 defined for the PIB could be used with NULL keys to provide an error- 363 detection mechanism, without requiring a key management mechanism. 364 However, this key-based method reuses a security mechanism for error 365 detection, which it is not designed for. As the Bundle Protocol has 366 no separate outer error detection covering this security payload, if 367 a private key is used, then third-party intermediate nodes that do 368 not possess that private key cannot determine the reliability of the 369 content, and would be unable to prevent unnecessary forwarding of 370 errored bundles belonging to non-error-tolerant applications. This 371 may lead to decreased performance of the network due to utilization 372 of storage, bandwidth, and power for unusable bundles, and poor end- 373 to-end performance due to the open nature of its control loop as 374 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. Having an error- 642 detecting checksum cover a previously encrypted block allows the 643 reliability of that block to be checked at intermediate nodes without 644 requiring decryption key, leading to earlier detection of errors and 645 earlier resends. This enables the intermediate network to help with 646 increasing the throughput and performance of the applications at the 647 end nodes. 649 5. Security Considerations 651 This document has attempted to assuage any security concerns that 652 would result from applying non-security-providing algorithms within a 653 mechanism intended for security. This is accomplished through 654 semantic overloading of the PIB, reusing its structure to hold a 655 simple checksum when it is not intended to provide security services. 657 The potential leakage of information if checksums are not covered by 658 some BSP confidentiality transform that is applied later in the 659 transmission path is eliminated by the fact that the existing PIB 660 block type code is used, and the BSP itself already contains rules 661 for ensuring that confidentiality transforms applied by the PCB 662 protect the security result fields within PIB instances. 664 This design decision to reuse a security block for error-detection 665 may seem bizarre to both security and networking experts. However, 666 this decision was necessitated by the late addition of checksum 667 support to the Bundle Protocol. By the time interest in this subject 668 arose within the DTNRG, the Bundle Protocol itself was in final 669 review phases and had been implemented multiple times. At the time 670 of this writing, the group did not have consensus that block 671 validation and payload error detection even belonged in the Bundle 672 Protocol itself. The Bundle Security Protocol was also no longer 673 malleable enough to ensure compatibility with checksum support, as it 674 had obtained a level of relative stability in its specification and 675 there were existing implementation efforts based on these which could 676 have required modification in order to not pass checksums carried in 677 a non-BSP block as unprotected after performing a confidentiality 678 transform of the payload. 680 In the authors' opinion, ideally, the error-detection functions would 681 be implemented within the basic networking portions of the Bundle 682 Protocol, and not as a subset of the security framework. However, 683 the existing Bundle Protocol design was too well-established for the 684 current definition of the Bundle Protocol to be affected. At this 685 time, the Bundle Protocol has only been proposed as Experimental with 686 some disclaimers. It is felt by some that future revisions of the 687 Bundle Protocol need to provide mechanisms ensuring error detection 688 for reliable delivery. In order to limit overhead, shorter 689 checksums, e.g. CRC-16, could be used for small blocks, with longer 690 checksums, e.g. MD5, reserved for large payload blocks. This would 691 allow checksums to cover and provide confident processing of even 692 blocks with mutable fields, and retain efficient updating in-network 693 as a mutable field changes, without the recomputation also covering 694 large unchanging payload blocks. This might also constrain the 695 damage caused by errors to the functions provided by an individual 696 block, rather than affecting the whole bundle and causing the whole 697 bundle to be discarded, although the overall value of this is 698 currently unknown. 700 The need to conserve limited network resources by detecting and 701 avoiding further propagating errored bundles in-transit means that 702 Bundle Agents SHOULD always validate checksums of in-flight bundles, 703 even if the Agents are not the ultimate destination. This opens the 704 door for a potential denial-of-service attack on DTN Bundle Agents by 705 forcing them to expend computational cycles on bundles with large 706 payloads. In this case, the attacker would also have to send these 707 bundles over some link towards the target Bundle Agent, which will 708 often be more constrained in bandwidth or availability than the 709 Bundle Agent is in compuational cycles, so this threat may be 710 unrealistic, or better combatted through access-control on links. If 711 this threat does turn out to be realistic in some set of 712 circumstances, intermediary validation of PIBs was intentionally left 713 as a SHOULD-level activity rather than a MUST, and could be 714 dynamically disabled at some threshold of CPU use. 716 Using the same protocol mechanism to provide (1) error-detection 717 without security claims, (2) error-detection using a security 718 protocol insecurely-keyed with a known NULL key, and (3) actual 719 security protection using the same protocol but with secret keys, any 720 of which can defined and used in the same "Payload Integrity Block", 721 is confusing at best, and not a good clean-sheet approach to helping 722 ensure secure configurations, interoperable implementations, or 723 efficient handling of errored bundles. 725 Use of a NULL key is inferior to separately handling the security 726 concerns of sender-authentication and integrity-protection from that 727 of error-checking, as it opens the door to private keys that prevent 728 standalone error-detection, and should be discouraged. Also, the 729 NULL key cannot provide error-detection needed for the mutable parts 730 of the bundle. Providing any error detection for the mutable parts 731 of the bundle has not been done here, and reliance on the fidelity of 732 mutable payloads should be avoided for this reason. 734 6. IANA Considerations 736 This document has no considerations for IANA. 738 7. Acknowledgements 740 Some of the work on this document was performed at NASA's Glenn 741 Research Center under funding from the Earth Science Technology 742 Office (ESTO) and the Space Communications Architecture Working Group 743 (SCAWG). 745 Discussion in the DTNRG and particular suggestions from 746 (alphabetically) Mike Demmer, Kevin Fall, Stephen Farrell, Darren 747 Long, Peter Lovell, and Susan Symington guided the genesis of this 748 document and were crucial to adding limited error-detection 749 capabilities to the Bundle Protocol within the existing pre- 750 established security framework. 752 8. References 754 8.1. Normative References 756 [I-D.irtf-dtnrg-bundle-security] 757 Symington, S., Farrell, S., Weiss, H., and P. Lovell, 758 "Bundle Security Protocol Specification", 759 draft-irtf-dtnrg-bundle-security-05 (work in progress), 760 February 2008. 762 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 763 April 1992. 765 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 766 Hashing for Message Authentication", RFC 2104, 767 February 1997. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 773 (SHA1)", RFC 3174, September 2001. 775 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 776 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 777 September 2002. 779 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 780 Specification", RFC 5050, November 2007. 782 8.2. Informative References 784 [I-D.farrell-dtnrg-km] 785 Farrell, S., "DTN Key Management Requirements", 786 draft-farrell-dtnrg-km-00 (work in progress), June 2007. 788 [I-D.irtf-dtnrg-sec-overview] 789 Farrell, S., Symington, S., Weiss, H., and P. Lovell, 790 "Delay-Tolerant Networking Security Overview", 791 draft-irtf-dtnrg-sec-overview-04 (work in progress) , 792 February 2008. 794 [I-D.irtf-dtnrg-tcp-clayer] 795 Demmer, M. and J. Ott, "Delay Tolerant Networking TCP 796 Convergence Layer Protocol", 797 draft-irtf-dtnrg-tcp-clayer-01 (work in progress), 798 February 2008. 800 [Koopman] Koopman, P., "32-bit cyclic redundancy codes for Internet 801 applications", Proceedings of the International Conference 802 on Dependable Systems and Networks (DSN), pp. 459- 803 468 2002, June 2002. 805 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 806 September 1981. 808 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 809 RFC 793, September 1981. 811 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 812 July 1994. 814 [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, 815 June 1995. 817 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 818 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 819 Networking Architecture", RFC 4838, April 2007. 821 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 822 Transmission Protocol - Security Extensions", RFC 5327, 823 September 2008. 825 [SGHP98] Stone, J., Greenwald, M., Hughes, J., and C. Partridge, 826 "Performance of checksums and CRCs over real data", IEEE 827 Transactions on Networks vol. 6 issue 5, pp. 529-543, 828 October 1998. 830 [SP00] Stone, J. and C. Partridge, "When the CRC and TCP Checksum 831 Disagree", Proceedings of ACM SIGCOMM 2000, 832 September 2000. 834 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-end Arguments 835 in System Design", ACM Transactions on Computer Systems 2 836 (4), November 1984. 838 Appendix A. Mandatory BSP Elements Needed to Implement Error-Detection 840 This document makes some BSP components mandatory to Bundle Protocol 841 implementations, in that while their use is optional they must be 842 supported for interoperability reasons. Previously, the BSP was 843 previously entirely optional. The appendix discusses these elements 844 in greater detail, and highlights some further drawbacks of basing 845 error detection and protocol reliability upon them. 847 A.1. Mutable Canonicalization 849 While impressively named, the mutable canonicalization procedure 850 should actually be quite simple to understand. The requirement for 851 mutable canonicalization stems from the Bundle Protocol's forwarding 852 design that allows several "mutable" fields (e.g. the "dictionary", 853 custodian, and some flags and length fields), to change in-transit at 854 intermediate nodes. In order for the checksum, MAC, or signature 855 computed and placed in the security result of a sent PIB to match the 856 result computed over the received bundle, the sender and receiver 857 need to leave mutable fields out of these computations. The format 858 of a bundle that is input to the PIB algorithms thus differs from its 859 wire-format, and is called its "mutable canonicalization". 861 Using mutable canonicalization implies either using an incrementally- 862 updatable checksum algorithm and feeding many small pieces of data to 863 it, or entirely rewriting a bundle block-by-block based on mutable 864 canonicalization rules before feeding it to the checksum function. 865 (The mutable fields still require protection against errors; a hop- 866 by-hop checksum over only the mutable fields could be used to provide 867 this. Hop-by-hop checksum coverage could be provided by a 868 convergence layer or BAB, but this would likely cover the entire 869 bundle or fragment.) 871 Several problems are known to plague mutable canonicalization: 873 1. [EDITOR'S NOTE: This concern may be easily fixed in updates to 874 the BSP document.] The Bundle Protocol specification describes 875 the bundle processing control flags as a single variable-length 876 SDNV whose bits are sub-divided in-order by function into "SRR" 877 (Status Report Request), "COS" (Class of Service), and "General". 878 The BSP's mutable canonicalization description shows three 879 separate fields, with only slightly differing names, but in 880 totally opposite order: "Proc. Flags", "COS Flags", and "SRR 881 Flags", instead of one single SDNV, yet has text that describes 882 operating on these as a single 64-bit value and applying a fixed- 883 length mask to them. This is unclear at best, and feared to be 884 uninteroperable in implementations. 886 2. Many bits within the bundle processing control flags are masked 887 out (i.e. forced to zero within) the mutable canonicalization 888 format. This includes all of the reserved class of service (COS) 889 bits that are highly likely to be needed to overcome the 890 limitation of having only three defined priority levels in the 891 Bundle Specification (compare to DiffServ, CLNP's priority field, 892 Aeronautical Mobile Radio Service message priorities, or 893 mechanisms in other networking stacks that provide many more 894 bits). This means that these bits, and any other bundle 895 processing control bits, will be unprotected by the end-to-end 896 checksum and may change in-transit, potentially causing mis- 897 treatment or mal-delivery of bundles. 899 3. The existing "bundle is a fragment" bit is unprotected in mutable 900 canonicalization. Errors in this bit itself can probably be 901 caught through other means, such as careful length and bound 902 checking in processing the rest of the bundle. 904 4. The entire mutable canonicalization procedure of parsing and re- 905 formatting bundles in order to perform a checksum validation is 906 significantly more complex than is typical in most existing 907 protocols that are designed to be capable of simply computing a 908 validation over a frame either without modifications [RFC1662], 909 with only a small fixed-length and position field masked 910 [RFC0791], or with only a simple fixed-size pseudoheader 911 [RFC0793]. The significant additional complexity of mutable 912 canonicalization prevents high performance in forwarding nodes 913 that follow the guideline of verifying unkeyed or NULL-keyed 914 PIBs. 916 A.2. PIB Format 918 PIBs follow the format of the abstract security block, defined in the 919 BSP specification [I-D.irtf-dtnrg-bundle-security], with a block type 920 code that identifies them as PIBs. Some of the processing rules for 921 PIBs that make the PIB less than ideal for error-detection purposes 922 include: 924 1. If a PCB is placed into a bundle that already has a PSB, then 925 another PCB is created that hides the PIB. This means that for 926 end-to-end error-detection PIBs, any in-network security proxies 927 that add PCB blocks also prevent the checksum in the PIB from 928 being verifiable before the PCB's security destination recovers 929 the cleartext PIB. If the PCB security destination is never 930 reached, the bundle cannot be checked for errors. Errored 931 bundles will consume resources between these two security 932 gateways, since the errors cannot be detected and the bundles 933 discarded en route. The RSA signature of such an errored bundle 934 will only fail at the security destination, and the bundle will 935 only be discarded at that end point, but there may be significant 936 resources expended in delivering the useless bundle to that 937 point. 939 2. A previously-generated PIB's security result cannot be retained 940 outside a PCB in the clear, because an observer could correlate 941 the value to some known probable plaintext payload value. It 942 might be better to reverse the order of operations and always 943 generate rewritten PIB ciphersuite checksums after generating 944 PCBs that encrypt the payload, so that the PIB security result 945 covers the PCB's encrypted form of the payload rather than the 946 unencrypted form, and uses the same security destination as the 947 PCB. Upon reaching this security destination, another PIB 948 destined for the receiver, covering the payload revealed at the 949 security destination, could be generated. Requiring this would 950 allow detection of errored bundles between PCB security source 951 and PCB security destination, but would involve adding another 952 instruction to the PCB generation process within the BSP. This 953 assumes no errors are introduced during the decryption process of 954 the PCB, as such errors would go undetected. If bundles pass 955 through nested security domains, this could compound the error 956 rate. 958 There seems to be both benefits and drawbacks to any approach to PIB 959 and PCB interaction that does not involve layering multiple PIBs that 960 can be pushed and popped off of a bundle at various security sources 961 and destinations. Pushing and popping nested PSBs approximates the 962 outer checksum around inner security payload used successfully 963 elsewhere in networking. By some reasonable metrics, the BSP- 964 prescribed interaction that we have attempted to build on and fix 965 here may be among the least desirable of all known methods for error 966 detection. 968 Authors' Addresses 970 Wesley M. Eddy 971 Verizon Federal Network Systems 972 NASA Glenn Research Center 973 21000 Brookpark Rd, MS 54-5 974 Cleveland, OH 44135 975 United States of America 977 Phone: +1-216-433-6682 978 Email: weddy@grc.nasa.gov 980 Lloyd Wood 981 Cisco Systems 982 11 New Square Park, Bedfont Lakes 983 Feltham, Middlesex TW14 8HA 984 United Kingdom 986 Phone: +44-20-8824-4236 987 Email: lwood@cisco.com 988 Will Ivancic 989 NASA Glenn Research Center 990 21000 Brookpark Road 991 Cleveland, Ohio 44135 992 USA 994 Phone: +1-216-433-3494 995 Fax: +1-216-433-8705 996 Email: William.D.Ivancic@nasa.gov 998 Full Copyright Statement 1000 Copyright (C) The IETF Trust (2008). 1002 This document is subject to the rights, licenses and restrictions 1003 contained in BCP 78, and except as set forth therein, the authors 1004 retain all their rights. 1006 This document and the information contained herein are provided on an 1007 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1008 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1009 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1010 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1011 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1012 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1014 Intellectual Property 1016 The IETF takes no position regarding the validity or scope of any 1017 Intellectual Property Rights or other rights that might be claimed to 1018 pertain to the implementation or use of the technology described in 1019 this document or the extent to which any license under such rights 1020 might or might not be available; nor does it represent that it has 1021 made any independent effort to identify any such rights. Information 1022 on the procedures with respect to rights in RFC documents can be 1023 found in BCP 78 and BCP 79. 1025 Copies of IPR disclosures made to the IETF Secretariat and any 1026 assurances of licenses to be made available, or the result of an 1027 attempt made to obtain a general license or permission for the use of 1028 such proprietary rights by implementers or users of this 1029 specification can be obtained from the IETF on-line IPR repository at 1030 http://www.ietf.org/ipr. 1032 The IETF invites any interested party to bring to its attention any 1033 copyrights, patents or patent applications, or other proprietary 1034 rights that may cover technology that may be required to implement 1035 this standard. Please address the information to the IETF at 1036 ietf-ipr@ietf.org.