Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring... --- 1/draft-pre-ch-21.txt 2008-05-05 21:50:48.813979300 -0700 +++ 2/draft-ietf-nfsv4-minorversion1-23.txt 2008-05-05 21:50:49.194564500 -0700 @@ -411,21 +411,22 @@ 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 552 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 552 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 556 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 556 20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 557 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from Client . . . . . . . . . . . . . . . . . . . . . . . . . 558 20.4. Operation 6: CB_NOTIFY - Notify directory changes . . . 562 20.5. Operation 7: CB_PUSH_DELEG - Offer Delegation to Client . . . . . . . . . . . . . . . . . . . . . . . . . 566 - 20.6. Operation 8: CB_RECALL_ANY - Keep any N delegations . . 567 + 20.6. Operation 8: CB_RECALL_ANY - Keep any N recallable + objects . . . . . . . . . . . . . . . . . . . . . . . . 567 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal Resources for Recallable Objects . . . . . . . . . . . . 570 20.8. Operation 10: CB_RECALL_SLOT - change flow control limits . . . . . . . . . . . . . . . . . . . . . . . . . 571 20.9. Operation 11: CB_SEQUENCE - Supply backchannel sequencing and control . . . . . . . . . . . . . . . . . 572 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending Delegation Wants . . . . . . . . . . . . . . . . . . . . 574 20.11. Operation 13: CB_NOTIFY_LOCK - Notify of possible lock availability . . . . . . . . . . . . . . . . . . . 575 @@ -26175,23 +26176,23 @@ If the client does return NFS4ERR_DELAY and there is a conflicting delegation request, the server MAY process it at the expense of the client that returned NFS4ERR_DELAY. The client's want will typically not be cancelled, but MAY processed behind other delegation requests or registered wants. When a client returns a status other than NFS4_OK, NFSERR_DELAY, or NFS4ERR_REJECT_DELAY, the want remains pending, although servers may decide to cancel the want by sending a CB_WANTS_CANCELLED. -20.6. Operation 8: CB_RECALL_ANY - Keep any N delegations +20.6. Operation 8: CB_RECALL_ANY - Keep any N recallable objects - Notify client to return all but N delegations. + Notify client to return all but N recallable objects. 20.6.1. ARGUMENT const RCA4_TYPE_MASK_RDATA_DLG = 0; const RCA4_TYPE_MASK_WDATA_DLG = 1; const RCA4_TYPE_MASK_DIR_DLG = 2; const RCA4_TYPE_MASK_FILE_LAYOUT = 3; const RCA4_TYPE_MASK_BLK_LAYOUT = 4; const RCA4_TYPE_MASK_OBJ_LAYOUT_MIN = 8; const RCA4_TYPE_MASK_OBJ_LAYOUT_MAX = 9; @@ -26761,110 +26762,108 @@ A server will probably not send an operation with code OP_CB_ILLEGAL but if it does, the response will be CB_ILLEGAL4res just as it would be with any other invalid operation code. Note that if the client gets an illegal operation code that is not OP_ILLEGAL, and if the client checks for legal operation codes during the XDR decode phase, then an instance of data type CB_ILLEGAL4res will not be returned. 21. Security Considerations - NFS has historically used a model where, from an authentication - perspective, the client was the entire machine, or at least the - source network address of the machine. The NFS server relied on the - NFS client to make the proper authentication of the end-user. The - NFS server in turn shared its files only to specific clients, as - identified by the client's source network address. Given this model, - the AUTH_SYS RPC security flavor simply identified the end-user using - the client to the NFS server. When processing NFS responses, the - client ensured that the responses came from the same network address - and port number that the request was sent to. While such a model is - easy to implement and simple to deploy and use, it is certainly not a - safe model. Thus, NFSv4.1 implementations are REQUIRED to support a - security model that uses end to end authentication, where an end-user - on a client mutually authenticates (via cryptographic schemes that do - not expose passwords or keys in the clear on the network) to a - principal on an NFS server. Consideration should also be given to - the integrity and privacy of NFS requests and responses. The issues - of end to end mutual authentication, integrity, and privacy are - discussed Section 2.2.1.1.1. + Historically the authentication of model of NFS had the entire + machine being the NFS client, and the NFS server trusting the NFS + client to authenticate the end-user. The NFS server in turn shared + its files only to specific clients, as identified by the client's + source network address. Given this model, the AUTH_SYS RPC security + flavor simply identified the end-user using the client to the NFS + server. When processing NFS responses, the client ensured that the + responses came from the same network address and port number that the + request was sent to. While such a model is easy to implement and + simple to deploy and use, it is unsafe. Thus, NFSv4.1 + implementations are REQUIRED to support a security model that uses + end to end authentication, where an end-user on a client mutually + authenticates (via cryptographic schemes that do not expose passwords + or keys in the clear on the network) to a principal on an NFS server. + Consideration is also be given to the integrity and privacy of NFS + requests and responses. The issues of end to end mutual + authentication, integrity, and privacy are discussed + Section 2.2.1.1.1. - Note that while NFSv4.1 mandates an end to end mutual authentication - model, the "classic" model of machine authentication via network - address checking and AUTH_SYS identification can still be supported - with the caveat that the AUTH_SYS flavor is neither REQUIRED nor - RECOMMENDED by this specification, and so interoperability via - AUTH_SYS is not assured. + Note that being REQUIRED to implement does not mean REQUIRED to use; + AUTH_SYS can be used by NFSv4.1 clients and servers. However, + AUTH_SYS is merely an OPTIONAL security flavor in NFSv4.1, and so + interoperability via AUTH_SYS is not assured. For reasons of reduced administration overhead, better performance and/or reduction of CPU utilization, users of NFSv4.1 implementations may opt to not use security mechanisms that enable integrity protection on each remote procedure call and response. The use of mechanisms without integrity leaves the user vulnerable to an attacker in the middle of the NFS client and server that modifies the RPC request and/or the response. While implementations are free to provide the option to use weaker security mechanisms, there are three operations in particular that warrant the implementation overriding user choices. - The first two such operations are SECINFO SECINFO_NO_NAME. It is - RECOMMENDED that the client send the either operation such that it is - protected with a security flavor that has integrity protection, such - as RPCSEC_GSS with either the rpc_gss_svc_integrity or + o The first two such operations are SECINFO SECINFO_NO_NAME. It is + RECOMMENDED that the client send the either operation such that it + is protected with a security flavor that has integrity protection, + such as RPCSEC_GSS with either the rpc_gss_svc_integrity or rpc_gss_svc_privacy service. Without integrity protection encapsulating SECINFO and SECINFO_NO_NAME and their results, an attacker in the middle could modify results such that the client - might select a weaker algorithm in the set allowed by server, making - the client and/or server vulnerable to further attacks. + might select a weaker algorithm in the set allowed by server, + making the client and/or server vulnerable to further attacks. - The second operation that should definitely use integrity protection - is any GETATTR for the fs_locations attribute. The attack has two - steps. First the attacker modifies the unprotected results of some - operation to return NFS4ERR_MOVED. Second, when the client follows - up with a GETATTR for the fs_locations attribute, the attacker - modifies the results to cause the client migrate its traffic to a - server controlled by the attacker. + o The third operation that should definitely use integrity + protection is any GETATTR for the fs_locations and + fs_locations_info attributes. The attack has two steps. First + the attacker modifies the unprotected results of some operation to + return NFS4ERR_MOVED. Second, when the client follows up with a + GETATTR for the fs_locations or fs_locations_info attributes, the + attacker modifies the results to cause the client migrate its + traffic to a server controlled by the attacker. Relative to previous NFS versions, NFSv4.1 has additional security considerations for pNFS (see Section 12.9 and Section 13.12), locking and session state (see Section 2.10.7.3). 22. IANA Considerations 22.1. Named Attribute Definitions - The NFSv4.1 protocol provides for the association of named attributes - to files. The name space identifiers for these attributes are - defined as string names. The protocol does not define the specific - assignment of the name space for these file attributes. Even though - the name space is not specifically controlled to prevent collisions, - an IANA registry has been created for the registration of NFSv4.1 - named attributes. Registration will be achieved through the + The NFSv4.1 protocol supports the association of a file with zero or + more named attributes. The name space identifiers for these + attributes are defined as string names. The protocol does not define + the specific assignment of the name space for these file attributes. + Even though the name space is not specifically controlled to prevent + collisions, an IANA registry has been created for the registration of + NFSv4.1 named attributes. Registration will be achieved through the publication of an Informational RFC and will require not only the name of the attribute but the syntax and semantics of the named attribute contents; the intent is to promote interoperability where common interests exist. While application developers are allowed to define and use attributes as needed, they are encouraged to register the attributes with IANA. Such registered named attributes are presumed to apply to all minor versions of NFSv4, including those defined subsequently to the registration. Where the named attribute is intended to be limited with regard to the minor versions for which they are not be used, the Informational RFC must clearly state the applicable limits. 22.2. ONC RPC Network Identifiers (netids) Section 3.3.9) discussed the r_netid field and the corresponding r_addr field within a netaddr4 structure. The NFSv4 protocol depends on the syntax and semantics of these fields to effectively - communicate callback information between client and server. + communicate callback and other information between client and server. Therefore, an IANA registry has been created to include the values defined in this document and to allow for future expansion based on transport usage/availability. Additions to this ONC RPC Network Identifier registry must be done with the publication of an RFC. The initial values for this registry are as follows (some of this text is replicated from Section 3.3.9 for clarity): The Network Identifier (or r_netid for short) is used to specify a transport protocol and associated universal address (or r_addr for @@ -26903,22 +26902,23 @@ to NFSv4. This requires a new minor version of NFSv4, and requires a standards track document from IETF. Another way to add a notification is to specify a new layout type. Notifications for new layout types would be requested via GETDEVICELIST (Section 18.41) and GETDEVICEINFO (Section 18.40). See Section 22.4). 22.4. Defining New Layout Types New layout type numbers will be requested from IANA. IANA will only provide layout type numbers for Standards Track RFCs approved by the - IESG, in accordance with Standards Action policy defined in RFC2434 - [20]. + IESG, in accordance with Standards Action policy defined in [20]. + All layout types assigned by IANA MUST be in the range 0x00000001 to + 0x7FFFFFFF. The author of a new pNFS layout specification must follow these steps to obtain acceptance of the layout type as a standard: 1. The author devises the new layout specification. 2. The new layout type specification MUST, at a minimum: * Define the contents of the layout-type-specific fields of the following data types: @@ -26942,20 +26942,22 @@ 1. Failure and restart for client, server, storage device. 2. Lease expiration from perspective of the active client, server, storage device. 3. Loss of layout state resulting in fencing of client access to storage devices (for an example, see Section 12.7.3). * A list of any new notification values for CB_NOTIFY_DEVICEID. + * A list of any new recallable object types for CB_RECALL_ANY. + * Include an IANA considerations section. * Include a security considerations section. 3. The author documents the new layout specification as an Internet Draft. 4. The author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" (STD 1). The new layout specification will be @@ -27173,29 +27175,32 @@ Burnett, and Charles Fan with contributions from Ted Anderson, Neil Brown, and Jon Haswell. The initial drafts for the Directory Delegations support were contributed by Saadia Khan with input from Dave Noveck, Mike Eisler, Carl Burnett, Ted Anderson and Tom Talpey. The initial drafts for the ACL explanations were contributed by Sam Falkner and Lisa Week. + The pNFS work was inspired by the NASD and OSD work done by Garth + Gibson. Gary Grider has also been a champion of high-performance + parallel I/O. Garth Gibson and Peter Corbett started the pNFS effort + with a problem statement document for IETF that formed the basis for + the pNFS work in NFSv4.1. + The initial drafts for the parallel NFS support were edited by Brent Welch and Garth Goodson. Additional authors for those documents were Benny Halevy, David Black, and Andy Adamson. Additional input came from the informal group which contributed to the construction of the initial pNFS drafts; specific acknowledgement goes to Gary Grider, Peter Corbett, Dave Noveck, Peter Honeyman, and Stephen Fridella. - The pNFS work was inspired by the NASD and OSD work done by Garth - Gibson. Gary Grider of the national labs (LANL) has also been a - champion of high-performance parallel I/O. Fredric Isaman found several errors in draft versions of the ONC RPC XDR description of the NFSv4.1 protocol. Audrey Van Bellingham provided, in numerous ways, essential co- ordination and management of the process of editing the specification drafts. Richard Jernigan gave feedback on the file layout's striping pattern design. @@ -27241,21 +27246,22 @@ Iyer, Suchit Kaura, Trond Myklebust, Anatoly Pinchuk, Spencer Shepler, Renu Tewari, Lisa Week, and Brent Welch. A review team worked together to generate the tables of assignments of error sets to operations and make sure that each such assignment had two or more people validating it. Participating in the process were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert Gordon, Trond Myklebust, Dave Noveck Spencer Shepler, Tom Talpey, Amy Weaver, and Lisa Week. - Others who provided comments include: Mahesh Siddheshwar. + Others who provided comments include: Jason Goldschmidt and Mahesh + Siddheshwar. Authors' Addresses Spencer Shepler Sun Microsystems, Inc. 7808 Moonflower Drive Austin, TX 78750 USA Phone: +1-512-401-1080