Subject: [nfsv4] Sessions RPC XID usage

From: "Talpey, Thomas" <[email-masked]>
Date: Wed, 23 May 2007 17:21:06 -0400

In the Sessions section review, we discussed how the presence of a
session affects the intepretation of the RPC XID by a receiver. It
was requested that this issue be brought to the list for clarification.

In traditional ONC RPC, the 32-bit xid serves to identify each RPC
request and reply. On any given connection (IP 5-tuple of addresses,
ports and protocol), equality of the xid implies request and reply are
associated. This property is used by the server to support replay
semantics, and by the client to demultiplex each reply.

This scheme falls apart quickly when XIDs and connection bindings are
not carefuly managed, leading to unreliable semantics for the reasons
mentioned in the draft (nonuniqueness due to transport rebinding, rapid
reuse, and overrun). The session, therefore, introduced a new request
identifier, the { sessionid, slotid, sequenceid } tuple. This identifier
enables the session to provide "perfect" exactly-once semantics,
across multiple ephemeral transport associations and (in the presence
of server persistence) across long spans of time.

The question therefore arises of how the RPC XID functions when there
is a new (better) identifier present. The answer, I argue, is "exactly
the same as before". But there are additional considerations.

First of all, the RPC XID remains in each message, and must be formulated
as before, uniquely on a per-connection basis. This is important for
several reasons (There are other reasons, but these are the big ones in
my view.):

1) The RPC layer must retain its existing semantics and implementation.
2) The client and server must be able to interoperate at the RPC layer,
prior to the NFSv4 decoding which will uncover the session information.
3) If no sessions is present (e.g. while being negotiated), or in case of
session-specific errors which void the session information, then the RPC
XID is necessary for correct operation.

There is no ambiguity here - the RPC XID must be generated by the
client and returned by the the server.

The question from the review however was, if the RPC XID has these
properties, why is the sessionid returned in the SEQUENCE operation?
The answer is convenience and improved correctness.

On the convenience issue, having the sessionid in the SEQUENCE results
of each reply means the client does not have to perform a lookup on the
associated session and its associated context. When multiple sessions
are sharing a single connection for resource-saving purposes, this is useful.

On the correctness issue, the connection sharing issue as well as any
trunking make including the sessionid necessary. The RPC XID is only
32 bits, and is frequently the source of correctness issues. As connections
are used for trunking multiple sessions, and for retrying requests previously
issued on other now-lost connections, this problem only gets worse.

If the RPC XID is deemed even a little bit inadequate to guarantee the
re-association of a reply with its request (as the draft argues), and since
the sequenceid and slotid only make sense in the scope of the session they
belong to, we need to provide the sessionid in the reply to provide the client
with all the tokens it needs to validate that the reply in fact belongs to the
matched request. So, this is the reson for the inclusion.

I want to stress again that this does not change the underlying meaning
of the RPC XID, it merely supplements it. I hope this note helps clarify some
of what's going on. Feel free to discuss further in any case.

Tom.

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

---

From: Rick Macklem <[email-masked]>
Date: Thu, 24 May 2007 11:04:32 -0400 (EDT)

On Wed, 23 May 2007, Talpey, Thomas wrote:

[good stuff snipped]
> semantics, and by the client to demultiplex each reply.

The only thing I'll add to Tom's discussion is...
Ric Werme is the resident expert, but my recollection w.r.t. the 
correctness issue for client demultiplexing is that it was caused by a
client reusing the same XID after a reboot and catching the reply from the
request issued before the reboot. Normally avoided by good selection of
an initial XID value after a client reboot. But it might be nice to
strengthen this for 4.1 by adding a sentence to the spec along the lines
of:
 	When available, the session sequenceid in the reply can be used
 	by a client as a sanity check to protect against faulty operation
 	due to demultiplexing via a reused XID.

rick

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 24 May 2007 11:05:03 -0400

> of what's going on. Feel free to discuss further in any case.

What you describe is fine by me.

I was under the impression during the confcall that there were server
vendors who wanted the freedom to always set the XID to zero on the RPC
reply. Not only would this violate the RPC protocol semantics as
described in RFC1831, it would also force clients to rewrite their
existing RPC stacks in order to do the reply matching in the NFS layer
instead of the RPC layer. A "minor version update" that is not...

Trond

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 24 May 2007 11:18:05 -0400

>client reusing the same XID after a reboot and catching the reply from the

Ric's presentation is at <http://www.connectathon.org/talks96/werme1.html>
1996!

The issue was reboot and also library-based implementations that selected
their xid from the clock, among other insanities (lok at what OS/2 did).

The sentence you suggest is fine except I would not say "sanity check",
I would suggest "correctness", since the { sessionid, slotid, sequenceid }
is the final arbiter of uniqueness/identity in the NFSv4.1 protocol and
therefore MUST be checked.

Tom.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 24 May 2007 11:29:43 -0400

>reply. Not only would this violate the RPC protocol semantics as

Right - totally invalid. I bet nobody admits to suggesting that though. ;-)

Servers MUST return the client's XID in the RPC header of their reply, whether
a session is in place or not.

Another way of saying this is that NFSv4.1 makes no normative requirements
of the RPC layer, outside of its implementation being RFC1831 compliant.

Tom.

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 24 May 2007 11:33:05 -0400

We have been primarily talking about the client here.
In the case of the client it is reasonable for initial
matching to be done by the client using the XID (and 
the server must not do anything like returning the XID
as zero, that would interfere with that) with a later
check of the sessionid/slotid/seqid to make sure that
that match is not a false positive.

On the other hand, on the server, no XID-based replay
cache check can be done.  If it were, and there were
a false positive, then any RPC-level  replay cache
handling would prevent NFSv4.1 from looking at it 
and doing the correct thing (i.e. noticing that the 
false positive is indeed false).

I mention this because points 2 and 3 in your original 
mail:

> 2) The client and server must be able to interoperate 
> at the RPC layer, prior to the NFSv4 decoding which will 
> uncover the session information.
> 3) If no sessions is present (e.g. while being negotiated), 
> or in case of session-specific errors which void the session 
> information, then the RPC XID is necessary for correct operation.

might be read as suggesting that for these periods (when there
is no session yet), an XID-based replay cache might be allowed
or even required.  As I understand it, that isn't the case, and
the protocol is intended not to require any XID-based replay
cache, even when a session has not been established yet

-----Original Message-----
From: Talpey, Thomas 
Sent: Thursday, May 24, 2007 11:18 AM
To: Rick Macklem
Cc: [email-masked]
Subject: Re: [nfsv4] Sessions RPC XID usage

>client reusing the same XID after a reboot and catching the reply from
the

Ric's presentation is at
<http://www.connectathon.org/talks96/werme1.html>
1996!

The issue was reboot and also library-based implementations that
selected
their xid from the clock, among other insanities (lok at what OS/2 did).

The sentence you suggest is fine except I would not say "sanity check",
I would suggest "correctness", since the { sessionid, slotid, sequenceid
}
is the final arbiter of uniqueness/identity in the NFSv4.1 protocol and
therefore MUST be checked.

Tom.