Subject: [nfsv4] SSV question

From: Fredric Isaman <[email-masked]>
Date: Thu, 6 Nov 2008 16:41:47 -0500 (EST)

We are beginning to implement SSV, and have a question.

Why would a client want multiple gss ssv handles?

My understanding is that a gss context is the client ID and its SSV 
history, which with the given algorithms uniquely define the 
GSS_[Get|Verify]MIC and GSS_[Wrap|Unwrap] functions, and the handle to be 
a string used to look up the context.

My best guess is that the gss seq_num is attached to the handle, not the 
context.  Is this the only intended difference between two handles?

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

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 6 Nov 2008 17:03:25 -0800 (PST)

> context.  Is this the only intended difference between two handles?

There are two sequence numbers (not including that in the SEQUENCE
operation) that matter here.

1. The sequence number in the RPCSEC_GSS credential. Increased by
   the client on each request.

2. The sequence number in the context of the SSV GSS mechanism. Increased
   by the client and server on each SET_SSV.

Multiple RPCSEC_GSS handles share a single SSV context. This
is likely different than how existing RPCSEC_GSS implementations
work over Kerberos V5 and other mechanisms. Given that RPCSEC_GSS
over Kerberos has an INIT phase, and RPCSEC_GSS over SSV does
not, I think we can safely assume that
"likely" --> "definitely".

Reasons to have multiple RPCSEC_GSS handles:

- higher throughput if an NFS client's multithreading implementation
  does not a handle to be used for two RPCs while both RPCs are outstanding.
  Arguably a weak reason given that the SSV mechanism has state that
  does not change very often, so there is little need to treat the
  access to the RPCSEC_GSS handle as a critical section.
  But not all GSS mechanisms are as obviously easy to multithread as
  SSV, and often the approach taken is not touch the GSS context
  while the RPC is in progress.

- when the RPCSEC_GSS handle's sequence number reaches MAXSEQ (0x80000000,
  I've no idea why it isn't 0xffffffff), the handle can no longer be used.
  I would rather have a handle ready to be used before I get to that point.
  So keeping two handles around, where one gets used, and the other
  is a spare, is a good idea.

- Some other reason I could not anticipate. Having an array of handles,
  future proofs against lack of imagination.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/