Subject: [nfsv4] draft-ietf-nfsv4-minorversion1: issue with seq_window on backchannel and SSV mechanism

From: "Mike Eisler" <[email-masked]>
Date: Tue, 9 Dec 2008 14:17:35 -0800 (PST)

Last night I was giving Ricardo Labiaga an overview of RPCSEC_GSS and
how it is used on NFSv4.1 backchannels when he asked about the seq_window
(see RFC 2203). We realized we have a couple of gaps in the currect
specification.

1. When CREATE_SESSION is called, it presents a list of RPCSEC_GSS
handles that are used for the backchannel (actually a list of
pairs: one member of the pair is the handle as returned by the server
from the response to an INIT command of the RPCSEC_GSS
protocol, and the other member of the pair is the handle that corresponds
to the first member, and is the handle the client wants the server to
use on the backchannel). Since RPCSEC_GSS/INIT is not used to create
a backchannel RPCSEC_GSS handle, the seq_window used for the backchannel
RPCSEC_GSS handle is not explicitly returned.

2. Like RPCSEC_GSS handles for the backchannel, RPCSEC_GSS handles for the
SSV mechanism (even for the fore channel) are not created via the INIT
command of RPCSEC_GSS (which would return the seq_window). Instead if
SP4_SSV protection is specified in EXCHANGE_ID, the server replies with
a list of nearly-ready to use RPCSEC_GSS handles that use the SSV mechanism.
(Nearly-ready because the spec disallows the use of the SSV mechanism until
a SET_SSV operation is sent; once SET_SSV succeeds, the RPCSEC_GSS handles
returned by EXCHANGE_ID can be used). At any rate, since RPCSEC_GSS/INIT
is not used to create these SSV-only handles, the seq_window is
not explicitly returned.

So we have two ways to go:

A. Change the .x file and add a seq_window result to the reply
  data structure of EXCHANGE_ID (SSV handles) and in the argument data
  structures (to specify the seq_window of backchannel
  RPCSEC_GSS handles) of CREATE_SESSION, and BINDCHANNEL_CTL

B. Add text that says the seq_window is implicit. For backchannel RPCSEC_GSS
  handles, it is always derivated from the corresponding forechannel
  handle. This means that the client (the target of the backchannel)
  might have to maintain an RPCSEC_GSS window that is larger than it needs.
  On the other hand, I gather that most RPCSEC_GSS target (server)
  implementations are implementing hard coded seq_windows (typically
  corresponding to the number of bits in the maximum sized scalar data
  type, usually 64 bits, but I believe at least one operating environment
  has a 128 bit integer data type, which would then enable a 128
  element (or with a neglible additional implementation effort, a 129
  element) RPCSEC_GSS  window, at the cost of storing 128 bits
  of information (i.e. "has the target received a request at sequence
  number corresponding to the bit?"). Thus I don't expect this
  to be onerous.

  For an RPCSEC_GSS SSV handle, seq_window would always be derived
  from that of handle of the RPCSEC_GSS credential that was used
  with the EXCHANGE_ID request that created the RPCSEC_GSS SSV handle.
  What if the EXCHANGE_ID request was not sent with RPCSEC_GSS
  protection? This is not allowed. -28 of the spec says (in the
  EXCHANGE_ID) description:

      SP4_SSV.  This choice is only valid if the client sent the request
      with RPCSEC_GSS as the security flavor, and with a service of
      RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY.  This choice
      indicates the client wants to use the SSV to protect state.  The
      server records the credential used in the request as the machine
      credential (as defined above) for the eia_clientowner.co_owner.
      The CREATE_SESSION operation that confirms the client ID MUST use
      the same machine credential.

  (The spec needs to insert a MUST in there).

Advantage of A: less potential ambiguity

Disadvantage of A:

- it is a .x file change, which could be
perceived by the community of potential NFSv4.1/pNFS implementors
a caution signal that the spec is not ready to commit a project
to.

- requires RPCSEC_GSS target (NFSv4.1 client and server)
  implementations to support an interface to
  read seq_window from an RPCSEC_GSS context
  (to support the seq_window value in the
  reply to EXCHANGE_ID) and to set the seq_window in an RPCSEC_GSS context
  (to support the seq_window value in the argument to CREATE_SESSION
  and BACKCHANNEL_CTL).

Advantage of B: Expedient.
Disadvantage of B:

- requires RPCSEC_GSS initiator implementations to support an
  interface to read seq_window from an existing RPCSEC_GSS context
  on both the NFSv4.1 client and server.

Thoughts?

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 09 Dec 2008 17:31:46 -0500

> Thoughts?

Could we perhaps add a RPCSEC_GSS_BIND_BACK_CHANNEL request to allow
bi-directional traffic in the rpcsec_gss v2 draft?

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 9 Dec 2008 14:42:44 -0800 (PST)

> bi-directional traffic in the rpcsec_gss v2 draft?

I do not think so.

RPCSEC_GSSv2 is an approved RFC (it even has a number assigned),
and is waiting for one minor editorial change from me before the RFC
Editor pushes it out.

There will likely be an RPCSEC_GSSv3 to support Mandatory Access Control
and Labeling; that would be an opportunity to add
RPCSEC_GSS_BIND_BACK_CHANNEL.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 09 Dec 2008 18:00:13 -0500

> RPCSEC_GSS_BIND_BACK_CHANNEL.

Right, but my point is that the real problem here is that RPCSEC_GSS
fails to define proper semantics for bi-directional RPC sessions,
whereas NFSv4.1 assumes that such semantics exist. We could hack such
semantics into the v4.1 draft, or we could fix it once and for all in
RPCSEC_GSS...

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 9 Dec 2008 16:27:10 -0800 (PST)

> semantics into the v4.1 draft, or we could fix it once and for all in

My points:

- "fix it once and for all" is a phrase that contains two probable
  falsehoods. Few things are fixed once or fixed for all.

- "hack such semantics in the v4.1 draft". One person's hack is another
  person's art. The "hack" has been in the spec for several years. We
  had inspections of the specification. The time to decide it
  was a hack was then. As I recall there was at least one protestation,
  but no rough consensus to do something else.

- We have a process. It is not an open ended process.
-- That process includes defining requirements. The
   requirements for RPCSEC_GSSv2 was to enable channel binding so that
   RPC/RDMA could be published as an RFC. At no time till today did we
   consider adding requirements to include reflective RPCSEC_GSS.
   The I-D that IESG approved conforms to the requirements that existed
   at the time.

-- The process includes deciding when it is time to deliver and when
   we have something that should stop delivery. This late in the
   process, something that stops delivery should be very severe.
   My opinion is this is not severe enough to change the over-the-network
   specification of RPCSEC_GSSv2 or NFSv4.1.

-- I doubt this will the only "hack", wart, or outright flaw.
   The process allows for future minor versions of NFSv4. That
   process has worked well beyond my own expectations. We can march toward
   perfection in v4.2, v4.3, ...

-- The process requires us to deliver documents on some semblance of
   schedule according to the WG charter.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Dec 2008 11:07:28 -0500

Trond wrote:
> whereas NFSv4.1 assumes that such semantics exist. 

It does?  I thought it was the case that each channel had its own RPC
session (bidirectional only in the sense that it deals with rpc requests
and responses).  Have I got that mixed up?

> We could hack such

Sure, but Mike's point is that that fix is not happening very soon.  So
if you assign the highest priority to once-and-for-all-ness, then you
could do this but the options are pretty unattractive, to put it mildly.

    Decide on a RPCSEC_GSS v3 to include this.  Make the v4.1 spec wait.
    Go thorough a non-trivial amount of time to do that and get it 
    approved and then resurrect v4.1, if anybody cares at that point.
    Then do the MAC stuff in RPCSEC_GSS v4.

    Or you could wait for MAC and do all of the stuff in RPCSEC_GSS v3.
    Then you go through a substantial amount of time with a non-trivial
    probability of non-success (we don't have "failure"), and get that 
    approved and then you know nobody will be interested in v4.1.

If you are saying "We can hack such semantics into the v4.1 draft",
given those alternatives, that sounds to be like by far the best choice.
I understand it would be nice to define the bidirectional RPC session
semantic in a RPCSEC_GSS v3.  Then NFS v4.2 could use it.  We would have
the choice of retaining the v4.1 approach as an option (the normal
path), or deciding that this is infrastructural, and making that
wholesale change in v4.2.

The point is that there is no reason not to do the bidirectional RPC
session work.  That can go on.  The issue is whether you have v4.1 wait
for that work or not.  If you don't, you have a hack or a wart or
whatever you want to call it, but nothing that is worse is than having
v4.1 wait a whole long time for this.  This is not a case where we
simply can't do what we want at this level.  I think we agree we can and
I don't see an adequate reason to make us not do it.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, December 09, 2008 6:00 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] draft-ietf-nfsv4-minorversion1: issue with
seq_window on backchannel and SSV mechanism

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 11 Dec 2008 22:03:21 -0800 (PST)

Proposed diffs are attached.

Index: nfsv41_middle_op_create_session.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_create_session.xml,v
retrieving revision 1.51
diff -c -r1.51 nfsv41_middle_op_create_session.xml
*** nfsv41_middle_op_create_session.xml	4 Sep 2008 23:00:15 -0000	1.51
--- nfsv41_middle_op_create_session.xml	12 Dec 2008 05:58:42 -0000
***************
*** 314,327 ****
  
  	    <vspace blankLines='1' />
  
!           Note that while the GSS context state is shared
!           between the fore and back RPCSEC_GSS contexts,
!           the fore and back RPCSEC_GSS context state
            are independent of each other as far as the
            RPCSEC_GSS sequence number (see the seq_num
            field in the rpc_gss_cred_t data type of Section
            5 and of Section 5.3.1, "RPC Request Header",
!           of <xref target="RFC2203" />).
  
  	    <vspace blankLines='1' />
  
--- 314,329 ----
  
  	    <vspace blankLines='1' />
  
!           Within each element of csa_sec_parms, the fore and back RPCSEC_GSS contexts MUST 
!           share the same GSS context
!           and must have the same seq_window
!           (see Section 5.2.3.1 of <xref target="RFC2203">RFC2203</xref>).
!           The fore and back RPCSEC_GSS context state
            are independent of each other as far as the
            RPCSEC_GSS sequence number (see the seq_num
            field in the rpc_gss_cred_t data type of Section
            5 and of Section 5.3.1, "RPC Request Header",
!           of RFC2203).
  
  	    <vspace blankLines='1' />
  
Index: nfsv41_middle_op_exchange_id.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_exchange_id.xml,v
retrieving revision 1.38
diff -c -r1.38 nfsv41_middle_op_exchange_id.xml
*** nfsv41_middle_op_exchange_id.xml	4 Dec 2008 00:36:32 -0000	1.38
--- nfsv41_middle_op_exchange_id.xml	12 Dec 2008 05:58:42 -0000
***************
*** 378,387 ****
        enforce state protection for the returned client ID.
       </t>
       <t>
!       SP4_MACH_CRED.  This choice is only valid if
!       the client sent the request with RPCSEC_GSS
        as the security flavor, and with a service of
!       RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY. The
        client wants to use an RPCSEC_GSS-based machine
        credential to protect its state. The server MUST note
        the principal the EXCHANGE_ID operation was sent
--- 378,388 ----
        enforce state protection for the returned client ID.
       </t>
       <t>
!       SP4_MACH_CRED.  If spa_how is SP4_MACH_CRED, then
!       the client MUST send the EXCHANGE_ID request with RPCSEC_GSS
        as the security flavor, and with a service of
!       RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED
!       is specified, then the
        client wants to use an RPCSEC_GSS-based machine
        credential to protect its state. The server MUST note
        the principal the EXCHANGE_ID operation was sent
***************
*** 401,410 ****
  
       </t>
       <t>
!       SP4_SSV. This choice is only valid if the client
!       sent the request with RPCSEC_GSS as the security
!       flavor, and with a service of RPC_GSS_SVC_INTEGRITY
!       or RPC_GSS_SVC_PRIVACY. This choice indicates
        the client wants to use the SSV to protect state.
        The server records the credential used in the request
        as the machine credential (as defined above) for
--- 402,412 ----
  
       </t>
       <t>
!       SP4_SSV. If spa_how is SP4_SSV, then
!       the client MUST send the EXCHANGE_ID request with RPCSEC_GSS
!       as the security flavor, and with a service of
!       RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY.
!       If SP4_SSV is specified, then
        the client wants to use the SSV to protect state.
        The server records the credential used in the request
        as the machine credential (as defined above) for
***************
*** 589,594 ****
--- 591,601 ----
         It is permissible for the client to set
         ssp_num_gss_handles to zero (0); the client can
         create more handles with another EXCHANGE_ID call.
+ 		 <vspace blankLines='1' />
+        The seq_window (see Section 5.2.3.1 of <xref target="RFC2203">RFC2203</xref>)
+        of each RPCSEC_GSS handle in spi_handle MUST be the same as the seq_window of
+        the RPCSEC_GSS handle used for the credential of the RPC request
+        that the EXCHANGE_ID request was sent with.
  
       </t>