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

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/