Subject: Minutes from nfsv4 WG meeting in Pittsburgh

From: Brent Callaghan <[email-masked]>
Date: Tue, 8 Aug 2000 16:42:25 -0700 (PDT)

Here's the minutes from the WG meetings last
week in Pittsburgh, Monday July 31st & August 1st.

	Brent

8< ------------------------

NFSv4 Working Group Meetings @ 48th IETF Pittsburgh
---------------------------------------------------

	Reported by Brent Callaghan

Monday Session (2 hours)
--------------

Document editor, Spencer Shepler, began by describing
some of the features of the NFSv4 implementation RFC
that he is working on.  The purpose of this Informational
RFC is to make information available to help implementors
of the protocol.  This information isn't strictly
necessary to describe the protocol, and would add 
unnecessary bulk to the NFS version 4 protocol 
specification.  As an example of content, Spencer
mentioned:

	- Filehandle construction
		Suggested content for persistent and volatile
		filehandles to follow correct semantics. Tradeoffs
		between persistent and volatile filehandles.
		Suggestions for how clients can recover from
		filehandle errors.

	- Internationalization
		NFS version 4 opens up file naming to any
		Unicode encoding via UTF8 wire encoding.
		Yet few filesystems support Unicode file
		naming.  The document will suggest how to
		deal with this.

	- Stateid and Clientid
		How to build these ids with the correct properties
		and how to recover from stateid and clientid
		errors.

	- Filesystem Interfaces
		NFSv4 implementations have to resolve v4
		filesystem semantics to local filesystems.
		The document will suggest how to resolve some
		of these semantic differences. Server implementations
		will also have to handle concurrent access to
		local filesystems from other protocols or local
		processes. In this case, other protocols might
		include NFS version 2 and 3 servers running
		concurrently on the same server host.  File locking
		interaction needs particular attention.

	- Missing Attributes
		No client or server can natively support all of the
		50 or more file and filesystem attributes in NFSv4.
		The server may need to approximate some attributes
		that it does not normally support, and clients
		need to be able to handle file attributes that
		may be missing on a particular server implementation.

	- File Migration and Replication
		The protocol specification describes errors and file
		attributes that support file migration and replication
		across server hosts.  However, it provides little
		guidance on how a server might successfully implement
		migration or replication. The document will lay out
		the server responsibilities in migrating or replicating
		filesystems, include client options in handling a
		migration/replication event, and suggest client
		strategies in choosing an optimal replica.

	- Access Control Lists
		NFSvr4 ACLs are modelled after those of Windows NT.
		Other filesystems support different ACL models
		based on POSIX ACLs or UNIX permission bits.
		Mapping of ACL semantics can be challenging.
		The document will suggest how this can be done.

Brent Callaghan gave a brief report on the recent NFSv4 bakeoff
event held in Santa Clara, CA. July 11-13. This is the third
event that tested NFSv4 interoperability.  The first bakeoff
was held October last year, and further v4 testing was seen
at Connectathon in March.  This bakeoff saw 7 implementations
from 5 organizations. New this time was an OpenBSD implementation
from the University of Michigan CITI group. Much use was made of
a v4-enhanced version of the snoop packet analyzer, and a Tcl-based
client called "nfsv4shell" that allowed testers to test NFSv4
operations interactively.

Brian Pawlowski presented possibilities for future work if the
working group is re-chartered. These include:

	- File Migration and replication
	- An SNMP MIB for server management
	- Name spaces described by LDAP schemas
	- A protocol for location of NFS services
	- Disconnected operation
	- ...

He listed some requirements and issues for migration and replication:

	- Migration is the movement of a filesystem from one server
	  to another in a way that is transparent to applications
	  that are using the migrated files.
	- Replication is the creation of one or more copies of the
	  filesystem.  It also implies the on-going maintenance
	  of replica synchronization, either by periodic resyncing
	  or continuous update of all replicas.
	- The NFS version 4 spec does not define the protocol used
	  to move or synchronize data between servers. Although this
	  provides system administrators with some flexibility, it
	  does not promote the construction of a robust migration
	  or replication protocol. Current protocol for migration and
	  replication are AFS/DFS, UNIX rdist and the rsync command.
	- There are some difficult problems in implementing migration
	  and replication:
		- Propagating updates efficiently
		- Minimizing client disruption
		- Atomicity guarantees
		- Replica integrity
		- Read-only vs read-write replication (write replication
		  is much harder)
		- File level vs block level replication
		- Multi-platform support.
		
Brian concluded with an interactive discussion on future work topics.
He suggested that the working group could be re-chartered to cover
a migration/replication project and suggested this as a simpler option
to the alternative of winding up the group and forming a new one.
A risk with pursuing this additional work is that it might drain
resources from the on-going standards-track work to take NFSv4
implementations to draft.  However, given the time it takes to take a
new protocol to the point at which it can be implemented, there is
likely little overlap in effort. Other projects that could be included
in a re-charter include an SNMP MIB to promote interoperable server
management and a name space project that could yield an implementation
document for naming.  There may be some interest in a disconnected
operation project, though this may be just an implementation issue,
and may not need the direct attention of a working group.

Tuesday Session (1 hour)
---------------

Brian Pawlowski lead an interactive discussion on the requirements
of a file migration and replication protocol. There are some sticky
issues with file migration: it is difficult to migrate or replicate
files with a consistent fileid attribute. Other file attributes
could be difficult to migrate or replicate, particularly across
heterogeneous filesystems. Atomicity guarantees may require filesystem
support of snapshots.

He provided an example of file migration in DFS. First, a filesystem
operation creates a read-only clone of the fileset to be migrated.
While this cloned fileset is moved, the read-write primary continues
to be updated. In a second phase, the primary is locked briefly to
all update traffic while the updates since the clone operation are
moved.  When the updates have been moved, the clients are switched
atomically to the fileset at the new location. Clients never see
a partially migrated fileset, the final atomic switch is not done
if there are any errors.  Although this method of migrating filesystems
is very efficient and convenient, it does require a lot of support
from the server's filesystem, e.g. the ability to create copy-on-write
clones, and to identify and move updates to the clone.

The rsync protocol (see www.samba.org) provides an efficient file-level
protocol for synchronization of file updates between two filesystems
over a TCP connection. It handles recovery from failed synchronization
and can detect and resolve file byte-range insertions and deletions.
It provides no support for atomicity.

Brian built a list of requirements for file migration/replication:

	- The protocol should be efficient and restartable with
	  the ability to update replicas incrementally.

	- It should be file-oriented, rather than block-oriented
	  as in mirroring protocols.

	- It should emphasize correctness in providing atomic
	  failover/migration from the client's point of view,
	  and guarantee that replicas are correctly synchronized.

	- The protocol should express file-level changes in compact
	  form and work well over limited bandwidth.

	- It should be secure from attacks that steal or change the data.

	- It needs to be scalable to huge filesystem, yet handle small
	  filesystems efficiently.

	- It must handle multiway replication and provide for
	  conflict resolution in changes between replicas.

	- Some discussion on how to deal with transfer of filesystem
	  state like locks.  According to Mike Kazar, AFS/DFS transferred
	  file locks as well.  This may be difficult to accomplish in
	  an atomic and heterogeneous way though.  A simpler strategy
	  was suggested: just handle the migration/failover event as
	  if the server had rebooted and let clients re-establish state
	  themselves.

Further discussion on the topic will be left to the mailing list.

Simon Cooper of SGI raised some concerns on NFSv4 security in the
final minutes of the meeting. He said that the RPCSEC_GSS RFC
leaves security negotiation up to the higher-level protocol, yet
NFSv4 doesn't describe security negotiation outside of GETSECINFO.
He suggested that it is inadequate since it does not require a 
secured connection between client and server.  Given the time
constraint, further discussion will be moved to the NFSv4 mailing
list.

-------------------------------

The slides from the meeting can be viewed at:

   http://playground.sun.com/pub/nfsv4/presentations/ietf48

------------------------

---

From: mre <[email-masked]>
Date: Tue, 8 Aug 2000 17:39:15 -0700 (PDT)

> constraint, further discussion will be moved to the NFSv4 mailing

Since SPKM-3 is a required GSS-API security mechanism for NFSv4,
clients merely invoke SECINFO under an RPCSEC_GSS session protected
with SPKM-3. Since SPKM-3 mandates 128 bit CAST and HMAC-MD5 as
mandatory protection algorithms, the client and server can negotiate
under an authenticated, tamper proof, and if desired, snoop proof
secure channel. Plenty of security until quantum computing is perfected.

So the server is required to provide a secure connection. 

The i-d could be clearer in explaining this though. I think it
was in an earlier draft, but this information might have
gotten lost, no doubt due to something else I asked Spencer to change.

However the i-d does say:

     It is recommended that the client issue the SECINFO call protected
     by a security triple that uses either rpc_gss_svc_integrity or
     rpc_gss_svc_privacy service. The use of rpc_gss_svc_none would
     allow an attacker in the middle to modify the SECINFO 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.

The three mandatory to implement mechanism associated with RPCSEC_GSS
are Kerberos V5, LIPKEY, and SPKM-3.  Kerberos V5, while mandatory to
implement, has enough infrastructure issues around it that it is
unreasonable to expect arbitrary clients and servers to be able make a
Kerberos V5 connection; what if for example the client and server are
in different realms, and no cross-realm configuration has been set up?
LIPKEY uses a client side password, passed after a secure SPKM-3
channel is establish. A password is not needed for secure negotiation;
only the server needs to be authentication (via its signed
certificate). So by deduction, that leaves SPKM-3 as the logical means
for clients to securely negotiate security with servers.

The proposed implementation i-d can shed more light on this. I'll be
happy to contribute text.

	-mre