idnits 2.17.00 (12 Aug 2021) /tmp/idnits63950/draft-eddy-dtnrg-checksum-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 403. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 203: '...his specification MUST support the MD5...' RFC 2119 keyword, line 221: '...ngth. Implementations SHOULD at least...' RFC 2119 keyword, line 227: '... SHOULD support at least receiving a...' RFC 2119 keyword, line 276: '...sible, then the bundle MAY be deleted....' 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 (August 14, 2007) is 5387 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1810 ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: draft-irtf-dtnrg-bundle-spec has been published as RFC 5050 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-spec (ref. 'SB07') == Outdated reference: draft-irtf-dtnrg-bundle-security has been published as RFC 6257 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Expires: February 15, 2008 L. Wood 5 Cisco Systems 6 August 14, 2007 8 The DTN Bundle Protocol Payload Checksum Block 9 draft-eddy-dtnrg-checksum-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Delay-Tolerant-Networking Bundle Protocol includes a custody 43 transfer mechanism to provide acknowledgements of receipt for 44 particular bundles. No checksum is included in the basic DTN Bundle 45 Protocol, however, so it is not possible to verify that bundles have 46 been either forwarded or passed through various convergence layers 47 without errors having been introduced. This document partially 48 rectifies the situation by defining a Bundle Protocol extension for 49 carrying payload checksums and describes how its use can be 50 integrated with both custody transfer and fragmentation. 52 Table of Contents 54 1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Payload Checksum Block Format . . . . . . . . . . . . . . . . 5 56 2.1. Checksum Algorithms . . . . . . . . . . . . . . . . . . . 6 57 3. Rules for Use . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . . . 14 67 1. Motivations 69 Reliable transmission of information is a well-known problem for all 70 protocol layers. Error detection and correction capabilities are 71 found in lower layers, but are also present in many higher-layer 72 protocols in order to detect residual bit errors and bugs. For 73 example, IPv4 verifies a simple header checksum before processing 74 inbound packets, even when running over a data link like Ethernet 75 that already performs a stronger CRC, and TCP and UDP segments 76 further includes a checksum covering their contents as well as some 77 IP header fields. What may seem like paranoia is actually not 78 unfounded, as errors in received data or packet corruption are known 79 to creep into packets from causes other than channel noise [SP00]. 80 Although coding of data on the channel can reduce the impact of 81 channel noise, end-to-end checksums are understood to be necessary 82 for applications requiring relative certainty that the data received 83 is error-free [SG98]. 85 The Delay/Disruption-Tolerant Networking (DTN) architecture [RFC4838] 86 is founded on an overlay of Bundle Agents (BAs), that forward data 87 units called bundles via a Bundle Protocol [SB07]. Bundles may be 88 lost or errored both during transmission between BAs, or within a BA 89 itself. Bundles belonging to applications that are not tolerant of 90 lost data have a "custody transfer" flag that requests reliable 91 transmission between bundle agents. Unfortunately, the notion of 92 reliability used in the basic custody transfer mechanism does not 93 take bit errors into account. It is assumed that the "convergence 94 layer adapters" that connect BAs to each other will detect and 95 correct errors before presenting bundle data to the BAs themselves. 96 This may be adequate in many cases, but is not always sufficient, and 97 the insufficiency is encapsulated in the well-known end-to-end 98 principle [RFC4838]. It is possible (and even statistically likely) 99 that either transmission errors will go unnoticed, or unchecked 100 errors will be introduced within a BA's memory, storage, or 101 forwarding systems. 103 For example, the UDP convergence-layer adapter that has been 104 popularly implemented in DTN stacks uses the usual IP 16-bit one's- 105 complement checksum to validate incoming packets. This checksum is 106 computed by summing 16-bit values within a packet. If two strings 107 within the packet of size greater than 16 bits are swapped in 108 position, the checksum will pass even though the datagram is now 109 different from the original, and clearly errored. The proposed TCP- 110 based convergence layer relies on the same checksum algorithm. This 111 checksum algorithm is considered weak, in that it does not detect a 112 class of subtle errors, but at least an attempt to verify that the 113 packet was as sent has been made. 115 Even stronger convergence-layer adapter error detection is not 116 sufficient. Errors within a BA's memory, errors due to memory issues 117 within the BA's host, e.g. radiation-induced soft errors, or errors 118 introduced from file-system corruption cannot be detected by 119 convergence layer adapters, as these errors occur in between 120 successive phases of forwarding and convergence-layer processing. 121 End-to-end computation and verification of checksums is required to 122 ensure integrity of DTN bundles forwarded across a system composed of 123 BAs and convergence layer adapters [SRC84]. 125 The proposed Bundle Security mechanisms [SFWP07] are capable of 126 providing an end-to-end checksum, but are intended for the very 127 different problem of security. The current design of Bundle Security 128 is not practical for simple integrity checking outside of a more 129 paranoid security context. For example, the Bundle Security 130 mechanisms include "mandatory ciphersuites" that implementations must 131 support. No simple checksum algorithm is among the mandated 132 algorithms. The mandated ciphersuites do include some more complex 133 keyed-hash constructions, but these rely on key management, which is 134 not appropriate for general integrity checking between multiple 135 parties simply relaying bundles. While it would be technically 136 possible to graft a non-security integrity-checking mechanism onto 137 the avaiable security mechanisms by specifying some assumed key, it 138 would be inapproriate for the problem at hand, and overkill. 139 Instead, it would be much simpler and less error-prone to implement a 140 separate checksum block for optional inclusion on bundles. Section 2 141 of this document defines such a block and Section 3 gives some simple 142 rules for its use. 144 2. Payload Checksum Block Format 146 A new bundle block, the Payload Checksum Block, is defined in this 147 section, for inclusion in bundles where integrity checking is 148 desirable. An un-keyed checksum algorithm is used. The integrity 149 verification that it provides covers only the bundle payload, as 150 several portions of other bundle blocks are allowed (and expected) to 151 change in-transit as a bundle is forwarded through a DTN. The 152 implications of this decision are discussed in the next section. 154 No Endpoint ID references are needed for this, so the layout follows 155 that of Figure 6 in the Bundle Protocol specification [SB07], with 156 its use of Self-Delimiting Numeric Values (SDNVs): 158 +-----------+-----------+-----------+-----------+ 159 |Block Type | Block Processing Ctrl Flags (SDNV)| 160 +-----------+-----------+-----------+-----------+ 161 | Block Length (SDNV) | 162 +-----------+-----------+-----------+-----------+ 163 | Checksum Algorithm (SDNV) | 164 +-----------+-----------+-----------+-----------+ 165 | | 166 | Payload Checksum Value | 167 | (variable length) | 168 | | 169 +-----------------------------------------------+ 171 Figure 1: Payload Checksum Block Format 173 The fields shown in Figure 1 above are defined as: 175 o Block Type - Implementations are currently using a value defined 176 as experimental in the Bundle Protocol Specification, but can be 177 expected to transition to an assigned value. 179 o Block Processing Ctrl Flags - The bits in this SDNV are defined in 180 the Bundle Protocol Specification. For Payload Checksum Blocks, 181 none of these bits need be set, except perhaps bit 3, to indicate 182 the "last block", when the block is sent as the final block in a 183 bundle. 185 o Block Length - This SDNV encodes the length of the remainder of 186 the Payload Checksum Block. When the Checksum Algorithm SDNV is 187 parsed, its length can be subtracted from the Block Length value 188 to determine the level of truncation for the Payload Checksum 189 Value, as explained below. 191 o Checksum Algorithm - This identifies the algorithm used to compute 192 the Payload Checksum Value field following it. Defined algorithms 193 are listed below. 195 o Payload Checksum Value - This is a raw string of octets whose 196 length is implied by the Block Length. This string contains the 197 checksum result computed over the Payload Block of the bundle, and 198 may only contain the high-order bits of this result, if truncation 199 is used to shorten the length of the checksum, as described below. 201 2.1. Checksum Algorithms 203 Any implementation of this specification MUST support the MD5 204 checksum algorithm [RFC1321]. MD5 has been chosen as the baseline 205 checksum algorithm in this mechanism because it represents a 206 reasonable tradeoff between robust error detection and efficiency of 207 implementation. For widespread use in DTNs, both resource-efficient 208 implementation and decent error-detection capabilities are needed. 209 MD5 algorithms are known to achieve processing several Mbps, even on 210 rather limited hardware [RFC1810], yet MD5 provides a much more 211 robust checksum than the Internet's 16-bit one's complement checksum. 212 Although MD5 has cryptographic weaknesses and is discouraged for use 213 in security protocols, concerns with resistance to pre-image 214 generation are irrelevant here as we are not using MD5 values in a 215 security context. 217 We also have a defined value to indicate use of SHA-1 checksums 218 [RFC3174]. However, support for SHA-1 checksums is not required. 219 SHA-1 is significantly less efficient than MD5 to compute in our 220 experience, for seemingly little added error-detection capability 221 when truncated to the same length. Implementations SHOULD at least 222 support receiving and verifying SHA-1 checksums. 224 An Adler-32 checksum option is also specified, but should be used 225 only in cases where bundle payloads are relatively small and 226 efficiency of computation is highly important. Implementations 227 SHOULD support at least receiving and verifying Adler-32 checksums. 229 The complete list of currently defined Checksum Algorithm values is: 231 +---+-----------+---------------------+ 232 | # | Algorithm | Un-Truncated Length | 233 +---+-----------+---------------------+ 234 | 0 | MD5 | 128 bits | 235 | | | | 236 | 1 | SHA-1 | 160 bits | 237 | | | | 238 | 2 | Adler-32 | 32 bits | 239 +---+-----------+---------------------+ 241 Other checksum algorithms may be assigned values in future documents. 243 3. Rules for Use 245 On small payloads, the relatively long output of the MD5 or SHA-1 246 algorithms might be viewed as a detriment to end-to-end application 247 performance by increasing the header overhead of the Bundle Protocol, 248 and reducing the capacity available to higher layers. For this 249 reason, senders of the Payload Checksum Block are permitted to 250 truncate the transmitted Payload Checksum Values if the full checksum 251 algorithm's output is deemed to be overly long in comparison to the 252 size of the payload. This should be done carefully at the sending 253 application's discretion, and never by default. When generating or 254 verifying a truncated checksum, it is understood that only the high- 255 order octets are included. 257 The checksum conveyed in the Payload Checksum Block only covers the 258 Payload Block of a bundle, and does not include any pseudoheaders 259 with EIDs, timestamps, etc., or any other portion of a bundle or its 260 other extension blocks. Ensuring robustness of bundle header 261 information and metadata is a separate problem not addressed here; 262 ideally each header would be self-checking to guarantee a degree of 263 robustness on receipt. 265 The checksum within the Payload Checksum Block has differing 266 semantics if it occurs before or after the Payload Block. If placed 267 before the Payload Block, then the Checksum Value should be 268 understood to cover the entire (unfragmented / reassembled) payload, 269 whereas if it follows the Payload Block within a Bundle Fragment, 270 then the Checksum Value only applies to the included fragment of the 271 payload. 273 Intermediate Bundle Agents, which may not be affiliated with either 274 the source nor the destination of a bundle, are permitted to verify 275 the Payload Checksum Block and attempt local recovery. If local 276 recovery is not possible, then the bundle MAY be deleted. 278 This document suggests amending the Bundle Protocol specification 279 with regard to Custody Transfer. Without any checksum verification, 280 claiming custody of a bundle is a potentially troublesome operation. 281 We suggest that the Bundle Protocol specification require the use of 282 a Payload Checksum Block when Custody Transfer is requested by an 283 application in order to close this gap. 285 4. Security Considerations 287 The mechanism described in this document does not introduce any new 288 security concerns beyond those present in the basic Bundle Protocol. 289 It only attempts to ensure the reliability of the Bundle Protocol 290 payload. Ensuring Bundle Protocol header reliability remains an open 291 problem. 293 5. IANA Considerations 295 This document has no considerations for IANA. 297 6. Acknowledgements 299 Some of the work on this document was performed at NASA's Glenn 300 Research Center under funding from the Earth Science Technology 301 Office (ESTO) and the Space Communications Architecture Working Group 302 (SCAWG). 304 7. References 306 7.1. Normative References 308 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 309 April 1992. 311 [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, 312 June 1995. 314 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 315 (SHA1)", RFC 3174, September 2001. 317 [SB07] Scott, K. and S. Burleigh, "Bundle Protocol 318 Specification", draft-irtf-dtnrg-bundle-spec-09 (work in 319 progress), April 2007. 321 7.2. Informative References 323 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 324 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 325 Networking Architecture", RFC 4838, April 2007. 327 [SFWP07] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 328 "Bundle Security Protocol Specification", 329 draft-irtf-dtnrg-bundle-security-03 (work in progress), 330 April 2007. 332 [SG98] Stone, J., Greenwald, M., Hughes, J., and C. Partridge, 333 "Performance of checksums and CRCs over real data", IEEE 334 Transactions on Networks vol. 6 issue 5, pp. 529-543. 336 [SP00] Stone, J. and C. Partridge, "When the CRC and TCP Checksum 337 Disagree", Proceedings of ACM SIGCOMM 2000, 338 September 2000. 340 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-end Arguments 341 in System Design", ACM Transactions on Computer Systems 2 342 (4), November 1984. 344 Authors' Addresses 346 Wesley M. Eddy 347 Verizon Federal Network Systems 348 NASA Glenn Research Center 349 21000 Brookpark Rd, MS 54-5 350 Cleveland, OH 44135 351 United States of America 353 Phone: +1-216-433-6682 354 Email: weddy@grc.nasa.gov 356 Lloyd Wood 357 Cisco Systems 358 11 New Square Park, Bedfont Lakes 359 Feltham, Middlesex TW14 8HA 360 United Kingcom 362 Phone: +44-20-8824-4236 363 Email: lwood@cisco.com 365 Full Copyright Statement 367 Copyright (C) The IETF Trust (2007). 369 This document is subject to the rights, licenses and restrictions 370 contained in BCP 78, and except as set forth therein, the authors 371 retain all their rights. 373 This document and the information contained herein are provided on an 374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 376 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 377 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 378 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 381 Intellectual Property 383 The IETF takes no position regarding the validity or scope of any 384 Intellectual Property Rights or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; nor does it represent that it has 388 made any independent effort to identify any such rights. Information 389 on the procedures with respect to rights in RFC documents can be 390 found in BCP 78 and BCP 79. 392 Copies of IPR disclosures made to the IETF Secretariat and any 393 assurances of licenses to be made available, or the result of an 394 attempt made to obtain a general license or permission for the use of 395 such proprietary rights by implementers or users of this 396 specification can be obtained from the IETF on-line IPR repository at 397 http://www.ietf.org/ipr. 399 The IETF invites any interested party to bring to its attention any 400 copyrights, patents or patent applications, or other proprietary 401 rights that may cover technology that may be required to implement 402 this standard. Please address the information to the IETF at 403 ietf-ipr@ietf.org. 405 Acknowledgment 407 Funding for the RFC Editor function is provided by the IETF 408 Administrative Support Activity (IASA).