idnits 2.17.1 draft-aggarwal-nfsv4-cksum-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 442. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 11, 2006) is 6560 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 220 -- Looks like a reference, but probably isn't: '2' on line 222 == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'Shepler' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC1071' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC1146' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC3309' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC3385' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'Stone' is defined on line 404, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) == Outdated reference: A later version (-29) exists of draft-ietf-nfsv4-minorversion1-00 -- Obsolete informational reference (is this intentional?): RFC 1146 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 3309 (Obsoleted by RFC 4960) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Aggarwal 3 Internet-Draft Sun Microsystems, Inc. 4 Expires: November 12, 2006 May 11, 2006 6 Extensions to NFSv4 for Checksums 7 draft-aggarwal-nfsv4-cksum-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 12, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document provides motivation for enhancing the NFSv4 protocol to 41 enable checksumming of data and describes extensions to NFSv4 in 42 order to enable such a capability. Discussion and suggestions for 43 improvements are requested. 45 Table of Contents 47 1. Security Considerations . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Checksum Extensions . . . . . . . . . . . . . . . . . . . . . 6 51 4.1. Checksum Algorithm Negotiation . . . . . . . . . . . . . . 6 52 4.2. Checksumming the READs and the WRITEs . . . . . . . . . . 6 53 4.3. New operation 40: CKINFO - Get server preferences on 54 checksum algorithms . . . . . . . . . . . . . . . . . . . 6 55 4.4. New operation 41: CKSUM - checksum values . . . . . . . . 8 56 4.5. Checksum Algorithm Considerations . . . . . . . . . . . . 10 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 6. Checksum Futures . . . . . . . . . . . . . . . . . . . . . . . 13 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 Intellectual Property and Copyright Statements . . . . . . . . . . 17 66 1. Security Considerations 68 None. 70 2. Introduction 72 The standard NFS protocol (without Kerberos) has historically relied 73 on the underlying transport for data integrity and it itself does not 74 make an attempt to ensure data integrity. Kerberised NFS provides 75 data integrity via the use of krb5i. 77 Version 4 of the Network File System (NFSv4) protocol specification 78 [RFC3530] employs TCP and Ethernet as its underlying transport 79 mechanism and it relies on these protocols to provide data integrity. 80 In order to ensure data integrity, TCP uses a one's complement of 16- 81 bit integers as its standard checksum. Its a weak checksum in that 82 its not resilient to multiple single bit errors cancelling out as 83 well as data re-arrangement and thus cannot be relied upon its error 84 detection capabilities. Ethernet, on the other hand, uses a 85 relatively strong checksum in the form of CRC32. However, this 86 checksum is not end-to-end and is computed at every hop thus 87 rendering the protection rather weak. 89 Given that the underlying transports don't provide enough protection, 90 the NFSv4 protocol (when deployed without Kerberos) needs to add its 91 own data integrity mechanisms in order to ensure sane data. Much 92 like other transport protocols, implementing checksums at the NFSv4 93 layer is an obvious choice. 95 Checksums for NFSv4 might be implemented for the entire NFS payload 96 or a part of the payload. This document proposes extensions to NFSv4 97 that might provide for a way to implement checksums for the READ/ 98 WRITE data portion of NFSv4 payload. 100 3. Requirements 102 One of the key requirements for NFSv4 checksums is to protect the 103 NFSv4 payload against network corruption occuring due to deficiencies 104 in the underlying transports. 106 As part of providing data integrity, it would be ideal if such a 107 scheme would allow for extending the protection domain from as close 108 as possible to where the data is generated, i.e. the application on 109 the client; to as close as possible to where its stored, i.e. the 110 storage on the server. Since end-to-end integrity is undeniably a 111 hard problem to solve, it would be a worthwhile to have the initial 112 specification allow for extensions such that end-to-end integrity can 113 be accomplished as part of future work. 115 Finally, any data integrity scheme should allow for providing the 116 flexibility to choose from a set of checksum algorithms. 118 4. Checksum Extensions 120 4.1. Checksum Algorithm Negotiation 122 In order for the client and server to checksum the data, they need to 123 arrive at a common checksum algorithm that both sides will use to 124 compute the checksum values. This can be accomplished by having the 125 client query the server for its preferences at the time of mounting 126 the filesystem. The server's preferences will serve as a hint for 127 the client as to what algorithm might be appropriate. 129 If it has been a priori determined that the server supports 130 checksums, the client will now add an extra operation, CKINFO, to the 131 mount compound. The server will respond with a list of checksum 132 algorithms it supports, in the order of preference. Given the 133 server's preferences and its own preferences, the client will 134 determine which algorithms to use. If the client determines that it 135 cannot support any of the algorithms supported by the server, it must 136 settle on using the "none" algorithm. That is, it must turn off 137 checksumming. 139 The checksum algorithm will need to be renegotiated in case of 140 failover events, migration events and while crossing server 141 boundaries. 143 4.2. Checksumming the READs and the WRITEs 145 After the algorithm preferences have been determined, all READ and 146 WRITE operations should be checksummed using the CKSUM operation. In 147 the case of a read, CKSUM should succeed READ and in the case of a 148 write, CKSUM should precede WRITE. 150 4.3. New operation 40: CKINFO - Get server preferences on checksum 151 algorithms 153 SYNOPSIS 155 cksum_algs 157 ARGUMENT 159 void; 161 RESULT 163 typedef struct cksum_alg4 { 164 uint32_t alg_num;/*maps to an algorithm name*/ 165 uint32_t alg_bits; 166 }; 168 typedef struct cksum_algs4 { 169 uint32_t alg_len; 170 cksum_alg4 alg_val<>; 171 }; 173 struct CKINFO4resok { 174 cksum_algs4 cksum_algs; 175 }; 177 union CKINFO4res switch (nfsstat4 status) { 178 case NFS4_OK: 179 CKINFO4resok resok4; 180 default: 181 void; 182 }; 184 DESCRIPTION 186 The CKINFO operation is added in the mount compound by the client 187 to gather a list of checksum algorithm preferences that the server 188 may have. The server responds by returning a list of algorithms 189 it supports in the order of preference. 191 The client should compute the intersection of algorithms supported 192 by the server and itself. 194 IMPLEMENTATION 196 The client gathers checksum preferences at mount time. The 197 preferences are essentially treated as hints as to which 198 algorithms may be best suited for future READ or WRITE operations 199 for a given file system. 201 If a server implementation supports finer grained checksumming 202 such as per-file based checksums, the preferences may often be 203 invalid. In such cases, the CKSUM operation (See Section 4.4) 204 will allow for the flexibility to enable per-file based checksums. 206 ERRORS 208 TBD 210 4.4. New operation 41: CKSUM - checksum values 212 SYNOPSIS 214 cksum_alg, cksum_val, cksum_alg_pref 216 ARGUMENT 218 union nfs4_cksum switch (cksum_alg4 alg.alg_num) { 219 case FLETCHER4: 220 uint64_t cksum[4]; 221 case SHA256: 222 uint64_t cksum[2]; 223 .. 225 default: 226 uint32_t error_status; 227 }; 229 struct CKSUM4args { 230 cksum_alg4 cksum_alg; 231 nfs4_cksum cksum_val; 232 cksum_alg4 cksum_alg_pref<>; 233 }; 235 RESULT 236 struct CKSUM4resok { 237 nfs4_cksum cksum_val; 238 cksum_stat4 sub_status; 239 cksum_alg4 cksum_alg; 240 cksum_alg4 cksum_alg_pref<>; 241 }; 243 union CKSUM4res switch (nfsstat4 status) { 244 case NFS4_OK: 245 CKSUM4resok resok4; 246 default: 247 void; 248 }; 250 DESCRIPTION 252 The CKSUM operation carries checksum value computed using the 253 algorithm specified in cksum_alg. It also specifies the client's 254 preferences in cksum_alg_pref. This operation is not intended to 255 be used as a standalone operation, rather in conjunction with the 256 READ or the WRITE operation. 258 When used with READ operation, this operation should follow the 259 READ. The client must set the checksum value to 0 to indicate 260 that a checksum wasn't computed because CKSUM is being compounded 261 with READ. The client should also set the checksum algorithm it 262 prefers in cksum_alg and its list of preferences in 263 cksum_alg_pref. 265 If the server supports the requested checksum algorithm, it 266 computes a checksum, over the READ data, using that algorithm. It 267 also indicates its preferences (if different from the client's) by 268 setting the cksum_alg_pref. 270 If the server doesn't support the requested algorithm (say, it 271 implements per-file checksums), it should compute the checksum 272 using one of the algorithms in cksum_alg_pref and indicate the 273 checksum algorithm used by setting cksum_alg as well as updating 274 the cksum_alg_pref in the results. If the server is not able to 275 support any of the algorithms out of cksum_alg_pref, it should 276 indicate that by setting the sub-status to NFS4ERR_WRONGALG. The 277 server may also consider specifying its preferences via 278 cksum_alg_pref. 280 The client should verify the checksum by computing a checksum over 281 the READ data using the algorithm specified in cksum_alg. 283 When used with the WRITE operation, CKSUM should precede the 284 WRITE. The client must compute the checksum over the WRITE data 285 and set cksum_alg to the algorithm that was used to compute the 286 checksum. It may also set indicate its algorithm preferences via 287 cksum_alg_pref. 289 The server must verify the checksum value by computing a checksum 290 over the WRITE data using the algorithm specified in cksum_alg. 291 If the checksum value matches, it should indicate success by 292 setting the status to NFS4_OK. If the checksum value matches but 293 the checksum algorithm, different than the one specified in 294 cksum_alg, is more suitable, it may be indicated by setting the 295 cksum_alg_pref. 297 If the checksum verification failed due to incorrect checksum, the 298 server will set the status to NFS4ERR_WRONGCKSUM. If the checksum 299 verification failed due to inability to support a particular 300 checksum algorithm, the server should indicate that by returning 301 an NFS4ERR_WRONGALG and optionally setting the cksum_alg_pref. If 302 the checksum verification failed due to an internal error, the 303 server should set the status to NFS4ERR_CKSUM. 305 IMPLEMENTATION 307 On a READ or a WRITE, if the client believes it wants to read the 308 data or write it regardless of the capabilities of the server, it 309 may specify that by specifying the "none" algorithm in its 310 preferences. Optionally, the client can just send the READ or a 311 WRITE without following it with CKSUM if it doesn't want the 312 server to use checksums entirely. The server should honour this 313 by successfully reading or writing the data without checksumming. 315 In the case of a READ, if the checksum verification on the client 316 side fails, its most beneficial for the client to retry the READ 317 atleast once in order to rule out transient errors. 319 Likewise for a WRITE, if the checksum verification on the server 320 fails, its most beneficial for the client to retry the WRITE 321 atleast once in order to rule out transient errors. 323 ERRORS 325 NFS4ERR_WRONGCKSUM NFS4ERR_CKSUM NFS4ERR_WRONGALG TBD 327 4.5. Checksum Algorithm Considerations 329 If the client and the server support checksums, they should support 330 atleast one of the recommended algorithms. Taking a cue from some of 331 the other newer protocols like SCTP and iSCSI, CRC32 is likely a good 332 candidate for a recommended algorithm. The "none" algorithm must 333 also be included as a recommended algorithm. 335 It is expected that the client and server may also support algorithms 336 beyond the recommended set of algorithms. 338 Algorithm names must not contain an at-sign("@"), a comma (",") or 339 whitespace or control characters. The algorithm names are case- 340 sensitive, and should not be longer than 256 characters [TBD: Is 341 there value in providing algorithm names longer than 256 characters] 343 User defined algorithms must be defined using names in the format 344 name@userdomainname, e.g., "ourchecksum@sun.com". All the rules from 345 above, except the use of the at-sign ("@") apply to user defined 346 algorithms. 348 5. IANA Considerations 350 The CKINFO and CKSUM operations carry algorithm numbers rather than 351 carrying algorithm strings over the wire. This makes implementations 352 easier as it eliminates the need for tedious string comparisons on 353 the client. 355 The constraint this brings about is that now there needs to be an 356 agreement on which algorithm numbers correspond to which algorithm 357 names. An IANA registry will need to be created to manage the 358 algorithm namespace. 360 6. Checksum Futures 362 This document proposes integrity protection for only the READ and 363 WRITE data between the client and the server. The rest of the 364 operations in the NFSv4 compound will not be protected. A natural 365 extension to this document would be to enhance the checksum 366 operations to enable protection for the entire NFSv4 compound. This 367 may or may not be akin to the krb5i protection. 369 7. Acknowledgements 371 Spencer Shepler and David Robinson 373 8. References 375 8.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 381 Beame, C., Eisler, M., and D. Noveck, "Network File System 382 (NFS) version 4 Protocol", RFC 3530, STD 1, April 2003. 384 [Shepler] Shepler, S., "NFS version 4 Minor Version 1", 385 draft-ietf-nfsv4-minorversion1-00 .txt, October 2005. 387 8.2. Informative References 389 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 390 Internet Checksum", RFC 1071, September 1988. 392 [RFC1146] Zweig, J. and C. Partridge, "TCP Alternate Checksum 393 Options", RFC 1146, March 1990. 395 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 396 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 397 September 2002. 399 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 400 "Internet Protocol Small Computer System Interface (iSCSI) 401 Cyclic Redundancy Check (CRC)/Checksum Considerations", 402 RFC 3385, September 2002. 404 [Stone] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 405 "Performance of Checksums and CRC's over Real Data", IEEE/ 406 ACM Transactions on Networking, Vol. 6,No. 5, 407 October 1998. 409 Author's Address 411 Alok Aggarwal 412 Sun Microsystems, Inc. 413 500 Eldorado Blvd. 414 MS: UBRM05-171 415 Broomfield, CO 80021 416 USA 418 Email: alok.aggarwal@sun.com 420 Intellectual Property Statement 422 The IETF takes no position regarding the validity or scope of any 423 Intellectual Property Rights or other rights that might be claimed to 424 pertain to the implementation or use of the technology described in 425 this document or the extent to which any license under such rights 426 might or might not be available; nor does it represent that it has 427 made any independent effort to identify any such rights. Information 428 on the procedures with respect to rights in RFC documents can be 429 found in BCP 78 and BCP 79. 431 Copies of IPR disclosures made to the IETF Secretariat and any 432 assurances of licenses to be made available, or the result of an 433 attempt made to obtain a general license or permission for the use of 434 such proprietary rights by implementers or users of this 435 specification can be obtained from the IETF on-line IPR repository at 436 http://www.ietf.org/ipr. 438 The IETF invites any interested party to bring to its attention any 439 copyrights, patents or patent applications, or other proprietary 440 rights that may cover technology that may be required to implement 441 this standard. Please address the information to the IETF at 442 ietf-ipr@ietf.org. 444 Disclaimer of Validity 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 449 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 450 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 451 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 454 Copyright Statement 456 Copyright (C) The Internet Society (2006). This document is subject 457 to the rights, licenses and restrictions contained in BCP 78, and 458 except as set forth therein, the authors retain all their rights. 460 Acknowledgment 462 Funding for the RFC Editor function is currently provided by the 463 Internet Society.