Internet DRAFT - draft-aggarwal-nfsv4-cksum
draft-aggarwal-nfsv4-cksum
Network Working Group A. Aggarwal
Internet-Draft Sun Microsystems, Inc.
Expires: November 12, 2006 May 11, 2006
Extensions to NFSv4 for Checksums
draft-aggarwal-nfsv4-cksum-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides motivation for enhancing the NFSv4 protocol to
enable checksumming of data and describes extensions to NFSv4 in
order to enable such a capability. Discussion and suggestions for
improvements are requested.
Aggarwal Expires November 12, 2006 [Page 1]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
Table of Contents
1. Security Considerations . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Checksum Extensions . . . . . . . . . . . . . . . . . . . . . 6
4.1. Checksum Algorithm Negotiation . . . . . . . . . . . . . . 6
4.2. Checksumming the READs and the WRITEs . . . . . . . . . . 6
4.3. New operation 40: CKINFO - Get server preferences on
checksum algorithms . . . . . . . . . . . . . . . . . . . 6
4.4. New operation 41: CKSUM - checksum values . . . . . . . . 8
4.5. Checksum Algorithm Considerations . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Checksum Futures . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Aggarwal Expires November 12, 2006 [Page 2]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
1. Security Considerations
None.
Aggarwal Expires November 12, 2006 [Page 3]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
2. Introduction
The standard NFS protocol (without Kerberos) has historically relied
on the underlying transport for data integrity and it itself does not
make an attempt to ensure data integrity. Kerberised NFS provides
data integrity via the use of krb5i.
Version 4 of the Network File System (NFSv4) protocol specification
[RFC3530] employs TCP and Ethernet as its underlying transport
mechanism and it relies on these protocols to provide data integrity.
In order to ensure data integrity, TCP uses a one's complement of 16-
bit integers as its standard checksum. Its a weak checksum in that
its not resilient to multiple single bit errors cancelling out as
well as data re-arrangement and thus cannot be relied upon its error
detection capabilities. Ethernet, on the other hand, uses a
relatively strong checksum in the form of CRC32. However, this
checksum is not end-to-end and is computed at every hop thus
rendering the protection rather weak.
Given that the underlying transports don't provide enough protection,
the NFSv4 protocol (when deployed without Kerberos) needs to add its
own data integrity mechanisms in order to ensure sane data. Much
like other transport protocols, implementing checksums at the NFSv4
layer is an obvious choice.
Checksums for NFSv4 might be implemented for the entire NFS payload
or a part of the payload. This document proposes extensions to NFSv4
that might provide for a way to implement checksums for the READ/
WRITE data portion of NFSv4 payload.
Aggarwal Expires November 12, 2006 [Page 4]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
3. Requirements
One of the key requirements for NFSv4 checksums is to protect the
NFSv4 payload against network corruption occuring due to deficiencies
in the underlying transports.
As part of providing data integrity, it would be ideal if such a
scheme would allow for extending the protection domain from as close
as possible to where the data is generated, i.e. the application on
the client; to as close as possible to where its stored, i.e. the
storage on the server. Since end-to-end integrity is undeniably a
hard problem to solve, it would be a worthwhile to have the initial
specification allow for extensions such that end-to-end integrity can
be accomplished as part of future work.
Finally, any data integrity scheme should allow for providing the
flexibility to choose from a set of checksum algorithms.
Aggarwal Expires November 12, 2006 [Page 5]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
4. Checksum Extensions
4.1. Checksum Algorithm Negotiation
In order for the client and server to checksum the data, they need to
arrive at a common checksum algorithm that both sides will use to
compute the checksum values. This can be accomplished by having the
client query the server for its preferences at the time of mounting
the filesystem. The server's preferences will serve as a hint for
the client as to what algorithm might be appropriate.
If it has been a priori determined that the server supports
checksums, the client will now add an extra operation, CKINFO, to the
mount compound. The server will respond with a list of checksum
algorithms it supports, in the order of preference. Given the
server's preferences and its own preferences, the client will
determine which algorithms to use. If the client determines that it
cannot support any of the algorithms supported by the server, it must
settle on using the "none" algorithm. That is, it must turn off
checksumming.
The checksum algorithm will need to be renegotiated in case of
failover events, migration events and while crossing server
boundaries.
4.2. Checksumming the READs and the WRITEs
After the algorithm preferences have been determined, all READ and
WRITE operations should be checksummed using the CKSUM operation. In
the case of a read, CKSUM should succeed READ and in the case of a
write, CKSUM should precede WRITE.
4.3. New operation 40: CKINFO - Get server preferences on checksum
algorithms
SYNOPSIS
cksum_algs
ARGUMENT
void;
Aggarwal Expires November 12, 2006 [Page 6]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
RESULT
typedef struct cksum_alg4 {
uint32_t alg_num;/*maps to an algorithm name*/
uint32_t alg_bits;
};
typedef struct cksum_algs4 {
uint32_t alg_len;
cksum_alg4 alg_val<>;
};
struct CKINFO4resok {
cksum_algs4 cksum_algs;
};
union CKINFO4res switch (nfsstat4 status) {
case NFS4_OK:
CKINFO4resok resok4;
default:
void;
};
DESCRIPTION
The CKINFO operation is added in the mount compound by the client
to gather a list of checksum algorithm preferences that the server
may have. The server responds by returning a list of algorithms
it supports in the order of preference.
The client should compute the intersection of algorithms supported
by the server and itself.
IMPLEMENTATION
The client gathers checksum preferences at mount time. The
preferences are essentially treated as hints as to which
algorithms may be best suited for future READ or WRITE operations
for a given file system.
If a server implementation supports finer grained checksumming
such as per-file based checksums, the preferences may often be
invalid. In such cases, the CKSUM operation (See Section 4.4)
will allow for the flexibility to enable per-file based checksums.
Aggarwal Expires November 12, 2006 [Page 7]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
ERRORS
TBD
4.4. New operation 41: CKSUM - checksum values
SYNOPSIS
cksum_alg, cksum_val, cksum_alg_pref
ARGUMENT
union nfs4_cksum switch (cksum_alg4 alg.alg_num) {
case FLETCHER4:
uint64_t cksum[4];
case SHA256:
uint64_t cksum[2];
..
default:
uint32_t error_status;
};
struct CKSUM4args {
cksum_alg4 cksum_alg;
nfs4_cksum cksum_val;
cksum_alg4 cksum_alg_pref<>;
};
RESULT
Aggarwal Expires November 12, 2006 [Page 8]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
struct CKSUM4resok {
nfs4_cksum cksum_val;
cksum_stat4 sub_status;
cksum_alg4 cksum_alg;
cksum_alg4 cksum_alg_pref<>;
};
union CKSUM4res switch (nfsstat4 status) {
case NFS4_OK:
CKSUM4resok resok4;
default:
void;
};
DESCRIPTION
The CKSUM operation carries checksum value computed using the
algorithm specified in cksum_alg. It also specifies the client's
preferences in cksum_alg_pref. This operation is not intended to
be used as a standalone operation, rather in conjunction with the
READ or the WRITE operation.
When used with READ operation, this operation should follow the
READ. The client must set the checksum value to 0 to indicate
that a checksum wasn't computed because CKSUM is being compounded
with READ. The client should also set the checksum algorithm it
prefers in cksum_alg and its list of preferences in
cksum_alg_pref.
If the server supports the requested checksum algorithm, it
computes a checksum, over the READ data, using that algorithm. It
also indicates its preferences (if different from the client's) by
setting the cksum_alg_pref.
If the server doesn't support the requested algorithm (say, it
implements per-file checksums), it should compute the checksum
using one of the algorithms in cksum_alg_pref and indicate the
checksum algorithm used by setting cksum_alg as well as updating
the cksum_alg_pref in the results. If the server is not able to
support any of the algorithms out of cksum_alg_pref, it should
indicate that by setting the sub-status to NFS4ERR_WRONGALG. The
server may also consider specifying its preferences via
cksum_alg_pref.
The client should verify the checksum by computing a checksum over
the READ data using the algorithm specified in cksum_alg.
Aggarwal Expires November 12, 2006 [Page 9]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
When used with the WRITE operation, CKSUM should precede the
WRITE. The client must compute the checksum over the WRITE data
and set cksum_alg to the algorithm that was used to compute the
checksum. It may also set indicate its algorithm preferences via
cksum_alg_pref.
The server must verify the checksum value by computing a checksum
over the WRITE data using the algorithm specified in cksum_alg.
If the checksum value matches, it should indicate success by
setting the status to NFS4_OK. If the checksum value matches but
the checksum algorithm, different than the one specified in
cksum_alg, is more suitable, it may be indicated by setting the
cksum_alg_pref.
If the checksum verification failed due to incorrect checksum, the
server will set the status to NFS4ERR_WRONGCKSUM. If the checksum
verification failed due to inability to support a particular
checksum algorithm, the server should indicate that by returning
an NFS4ERR_WRONGALG and optionally setting the cksum_alg_pref. If
the checksum verification failed due to an internal error, the
server should set the status to NFS4ERR_CKSUM.
IMPLEMENTATION
On a READ or a WRITE, if the client believes it wants to read the
data or write it regardless of the capabilities of the server, it
may specify that by specifying the "none" algorithm in its
preferences. Optionally, the client can just send the READ or a
WRITE without following it with CKSUM if it doesn't want the
server to use checksums entirely. The server should honour this
by successfully reading or writing the data without checksumming.
In the case of a READ, if the checksum verification on the client
side fails, its most beneficial for the client to retry the READ
atleast once in order to rule out transient errors.
Likewise for a WRITE, if the checksum verification on the server
fails, its most beneficial for the client to retry the WRITE
atleast once in order to rule out transient errors.
ERRORS
NFS4ERR_WRONGCKSUM NFS4ERR_CKSUM NFS4ERR_WRONGALG TBD
4.5. Checksum Algorithm Considerations
If the client and the server support checksums, they should support
atleast one of the recommended algorithms. Taking a cue from some of
Aggarwal Expires November 12, 2006 [Page 10]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
the other newer protocols like SCTP and iSCSI, CRC32 is likely a good
candidate for a recommended algorithm. The "none" algorithm must
also be included as a recommended algorithm.
It is expected that the client and server may also support algorithms
beyond the recommended set of algorithms.
Algorithm names must not contain an at-sign("@"), a comma (",") or
whitespace or control characters. The algorithm names are case-
sensitive, and should not be longer than 256 characters [TBD: Is
there value in providing algorithm names longer than 256 characters]
User defined algorithms must be defined using names in the format
name@userdomainname, e.g., "ourchecksum@sun.com". All the rules from
above, except the use of the at-sign ("@") apply to user defined
algorithms.
Aggarwal Expires November 12, 2006 [Page 11]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
5. IANA Considerations
The CKINFO and CKSUM operations carry algorithm numbers rather than
carrying algorithm strings over the wire. This makes implementations
easier as it eliminates the need for tedious string comparisons on
the client.
The constraint this brings about is that now there needs to be an
agreement on which algorithm numbers correspond to which algorithm
names. An IANA registry will need to be created to manage the
algorithm namespace.
Aggarwal Expires November 12, 2006 [Page 12]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
6. Checksum Futures
This document proposes integrity protection for only the READ and
WRITE data between the client and the server. The rest of the
operations in the NFSv4 compound will not be protected. A natural
extension to this document would be to enhance the checksum
operations to enable protection for the entire NFSv4 compound. This
may or may not be akin to the krb5i protection.
Aggarwal Expires November 12, 2006 [Page 13]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
7. Acknowledgements
Spencer Shepler and David Robinson
Aggarwal Expires November 12, 2006 [Page 14]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, STD 1, April 2003.
[Shepler] Shepler, S., "NFS version 4 Minor Version 1",
draft-ietf-nfsv4-minorversion1-00 .txt, October 2005.
8.2. Informative References
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988.
[RFC1146] Zweig, J. and C. Partridge, "TCP Alternate Checksum
Options", RFC 1146, March 1990.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
"Internet Protocol Small Computer System Interface (iSCSI)
Cyclic Redundancy Check (CRC)/Checksum Considerations",
RFC 3385, September 2002.
[Stone] Stone, J., Greenwald, M., Partridge, C., and J. Hughes,
"Performance of Checksums and CRC's over Real Data", IEEE/
ACM Transactions on Networking, Vol. 6,No. 5,
October 1998.
Aggarwal Expires November 12, 2006 [Page 15]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
Author's Address
Alok Aggarwal
Sun Microsystems, Inc.
500 Eldorado Blvd.
MS: UBRM05-171
Broomfield, CO 80021
USA
Email: alok.aggarwal@sun.com
Aggarwal Expires November 12, 2006 [Page 16]
Internet-Draft Extensions to NFSv4 for Checksums May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aggarwal Expires November 12, 2006 [Page 17]
