Subject: [nfsv4] Notes from part 3 of the sessions review panel

From: Trond Myklebust <[email-masked]>
Date: Mon, 21 May 2007 14:27:48 -0400

Fred Isaman          (CITI) -
Spencer Shepler      (Sun)    Moderator -
Mike Eisler          (NetApp) Author -
Trond Myklebust      (NetApp) Scribe -
Dave Noveck          (NetApp) -
John Scott           (NetApp) -
Peter Shah           (NetApp) -
Tom Talpey           (NetApp) Reader -
Benny Halevy         (Panasas) -
Rick Macklem         (Guelph) -

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

Talpey EXCHANGE_ID will not be discussed.

Talpey 22151:	The header pad size is used to align. It will be channel-
		specific rather than session-specific.

Noveck  22218:	The client MAY precede, but the server MUST accept a
		create_session with no preceding SEQUENCE. What should it be?

	22241:	use of the word 'bound' see Doeppner's previous comments
		on that issue.

Talpey  22269:	"..records a contrived CREATE_SESSION" is not normative
		text. Is really implementation advice.
Noveck	 	This is in an "implementation" section...

Myklebust 22281: Could an attacker use this to replay the CREATE_SESSION
		request and obtain the secret conn_binding4res_info.
Noveck:		Don't we require that the principal be the same?
Isaman:		See step 3. which talks about the principal....
	To be raised as an issue on the list...

Talpey 22302:	"In case the state for... " should refer to creation of the
		'first' session.

	22315:	Common case is 'first session'
Noveck:		Principal Change or collision is also 'first session'.
		Rewrite this to describe 'normal case'
		and 'bad case' separately...

Isaman 22332:	sequence_arg is not mentioned anywhere else in the spec.

Noveck 22373:	This paragraph is not valid. See previous comments on
		Metadata servers need to support persistent sessions

Myklebust 22390: How do you handle a replay of a CREATE_SESSION request
		that includes a CREATE_SESSION4_FLAG_CONN_RDMA
Talpey:		Client should replay on a new connection. Then server will
		replay from cache.
Noveck:		Reply has a side-effect. You have to alter the transport
		state.
Talpey:		Server doesn't really need to replay. It might no longer
		have RDMA capabilities.
		Really only need text to describe the replay side-effect:
		whereby transport needs to be reinitialised...
		Other data such as number of slots may also change on replay.

Halevy:		Move the description of the fields out of the
		implementation section (most of para 4 in section 17.3.4).

		Acked by everyone...
----
Isaman 22439:	cbr_enforce MUST be the same as cba_enforce. Why?
----
Doeppner 22472: Get rid of blank lines to ensure people see the para applies
		to both
		Concensus on this
----
Macklem		Use fore_chan & back_channel instead of "operations channel"
----
Isaman		It is possible for a client to send values where the server
		cannot ever set up a response:
			i.e. cannot reply with an NFS4ERR_INVAL/TOO_BIG
		needs a comment.
Noveck:		2.10.44 should have text that addresses this issue.
Isaman:		Just state that the server may exceed the buffer size in
		order to return the error.
Eisler:		Don't want to put too much intelligence in server for
		checking aberrant client data.
Noveck:		Agrees with Isaman
		Concensus
------------
Halevy:		Text is unclear on issue of ca_maxresponsesize negotiation
		Will take a suggestion offline...
------------
Talpey 22520:	Confused about client and server: need to use 'sender'
		and 'receiver' for consistency.
Macklem 	Use "Reply cache" instead of request cache etc...
------------
Halevy 22537:	Is 0xFFFFFFFF an 'increase' in the sense of the next
		sentence? Can a server reply 0xFFFFFFFF in response to
		a client request that has a limit?
Eisler:		No 0xFFFFFFFF is a value, not a flag.
		Get rid of that sentence "If client or server...":
		it is confusing.
		Concensus...
-----------
Talpey 22554:	Why a 1 element array?
Eisler:		That is equivalent to an XDR union...
-----------
Isaman 22560:	Why is csa_cb_program a per session value?
Eisler:		See the v4.0 protocol. Have rpc program number in
		SETCLIENTID.
		Need to fix a version number (to 4?).
Halevy:		Do we need a minor version number?
Scott:		NetApp uses the same as the protocol minor version.
-----------
Talpey 22577:	"client" -> "sender"?
Eisler:		The client is authorising the server to use AUTH_NULL.
------------
Myklebust:	Question about RPCSEC_GSS context: should that be "principal"
Eisler:		No. Use actual RPCSEC_GSS context set up by client.
		Would be useful to prototype this before we publish RFC.
----------
Talpey 22641:	We shouldn't be talking about the replay cache here. That is
		an implementation issue.
Eisler:		(Substitute replay cache -> reply cache)
Talpey:		Should just say: reply NFS4ERR_SEQ_MISORDERED if the sender
		doesn't start with seqid == 0.
----------
Talpey 22686:	Security issue with DESTROY_SESSION. Can anybody do it?
Eisler:		SSV fixups will solve this issue. Need to add an SSV field
		into DESTROY_SESSION.
		Propose that DESTROY_SESSION is only allowed from a connection
		that is bound to that session. Makes consistent with the
		general security model used elsewhere.
-----------
Talpey 22715:	Any plan to write text here?
Eisler:		No.
Talpey:		No errors section.
Eisler:		We want to get rid of that and replace with the section
		that maps errors and operations.
-------------
Isaman 21541:	What happens if the client doesn't follow up? Is state lost?
		Is there a deadline?
Eisler:		Server needs latitude to cache beyond lease period if the
		latter is short.
		Perhaps propose that the client may have 1 outstanding per
		session?
--------------
Talpey 21565:	bdri_nonce3 is not defined anywhere.
Isaman:		It is defined in the .x file.
		'Otherwise' assumes that if the challenge is false, then you
		are in the second part of something. What if the server
		chooses not to challenge at all (as allowed in line 21543)?
		There is no guidance...
Scott:		Is nonce3 a typo?

		Leave it to the authors to figure out....
-------------
Talpey 21583:	"the server MUST return CDFS4_BACK". Server can fail...
-------------
Talpey 21635:	Strike the word 'machine'
Eisler:		Acked.
-------------
Talpey 21654:	Delete the Errors section
Eisler:		Ack
-------------
Myklebust 23773: sessionid needed here?
Eisler:		Don't want to depend on the XID. The same connection may
		serve multiple sessions.
Shepler:	Clients cannot demux without XID since this is not a
		self-describing protocol.
Eisler:		Do we allow replies to return on a different connection than
		the one the client sent the request on?
	Leave as an open issue.
-------------

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4