Subject: Re: [nfsv4] Issue with section 3.2.5.1?

From: "Noveck, David" <[email-masked]>
Date: Mon, 2 Sep 2013 20:22:17 -0400

I don't see any reference to Mike Eisler's proposal in regard to this.  See http://www.ietf.org/mail-archive/web/nfsv4/current/msg12187.html

What you call the third proposal is not, as I understand it, an alternative to the other two.  It is Trond's way of dealing with a different issue. 

The problem is that we expect the client to open the source file and get a stateid on the source server and pass that to the destination server.
The assumption had been that the destination server could just use that in the READ it issued to the source server.  The problems is that, in
v41 and beyond, stateids are tied to clientid's and you cannot just use someone else's stateid on a session associated with your clientid.   

-----Original Message-----
From: Andy Adamson [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 5:30 PM
To: Noveck, David
Cc: Myklebust, Trond; Haynes, Tom; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] Issue with section 3.2.5.1?

Since I am deciding whether or not to proceed with finishing draft-ietf-nfsv4-rpcsec-gssv3, I would like to first summarize where I think we stand.

AFAICS there are three proposals for SSC: NFSv4.2 SSC with RPCSEC_GSS_V3, NFSv4.2 SSC without RPCSEC_GSS_V3, and NFSv4.2 SSC without RPCSEC_GSS_V3 and with proposed SSV. I think I pretty much get the first two, which I summarize in the attachment.

Since the the third SSV proposal has not really been discussed, I have some questions to stimulate a discussion :) So if you want to cut to the quick,  ignore the  attachment and just look below where I ask some SSV questions.

Hi Trond:

Here are some of your responses in this email stream:

--- From Trond:
If you are worried about spoofing, then one solution might be to have COPY_NOTIFY return an SSV that the destination server can use as part of an SSV GSS authentication for the actual READ and WRITE requests.

and

See my response to Dave. I suggest having COPY_NOTIFY return an SSV for use by the destination server to tie the use of this stateid in GSS SSV-authenticated READ requests to this client (and you can even tie it to this specific COPY operation).

finally:

Again, the point of the SSV is to ensure that the source ties the ca_src_stateid to the specific COPY_NOTIFY operation that generated it.
IOW: the source can use that to map the ca_src_stateid back to the client id of the _client_ which issued the COPY_NOTIFY.

----

Not having any SSV use design description other than above, I have some initial questions. I also must say that I'm just wrapping my head around SSV, so I may not understand all of it. Anyway, I need to understand better what is being proposed.

Questions:

1) As described in rfc5661 Section 2.10.9, the establisment of an SSV is tied to SP4_SSV in EXCHANGE_ID which is the only way to setup a GSS SSV context. So for an SSV to be used to authenticate the READ requests from the destination server acting as a client (herafter called the ds_client), said SSV must be setup via an EXCHANGE_ID from the ds_client to the source server.

Is the <ds_client,source server> clientid SSV the one that COPY_NOTIFY will return for use by the ds_client or are you proposing a new way to setup an SSV?

2) If the <ds_client,source server> clientid SSV is the one COPY_NOTIFY will return, how does the source server grant permission for the COPY_NOTIFY to do so, considering the COPY_NOTIFY is associated with a different clientid :the <client, source server> clientid?

3) rfc5661 Section 2.10.8.3. "Protection from Unauthorized State Changes" notes:

   The SP4_SSV protection option is intended for the
   situation comprised of a client that has multiple active users and a
   system administrator who wants to avoid the burden of installing a
   permanent machine credential on each client.

and
      Each time a
      new principal uses a client ID for the first time, the client
      SHOULD send a SET_SSV with that principal's RPCSEC_GSS
      credentials, with RPCSEC_GSS service set to RPC_GSS_SVC_PRIVACY.

Are you saying that the <ds_client, source server> clientid establishment use SP4_SSV?

If so, what happnens if another principal wants to use the session created under the SSV that the COPY_NOTIFY has grabbbed, and before the READ operation. SET_SSV has been called - doesn't that change the current SSV so that the old SSV presented by COPY_NOTIFY is no longer valid? Or don't I get SET_SSV :) ?

Thanks

-->Andy

On Wed, Aug 14, 2013 at 1:59 PM, Noveck, David <[email-masked]> wrote:
>> That's what the SSV is for. The _source_ server would provide the 
>> SSV, and therefore can use that to authenticate the READ operations. 
>> The SSV will actually tie the entire set of READ requests to the specific COPY_NOTIFY request.
>
> Understood, but my point was that someone is going to have to describe 
> that in the spec in a way that client and source server and 
> destination server implementers can read and follow, so that they will all interoperate.
>
>
> -----Original Message-----
> From: Myklebust, Trond [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2013 1:22 PM
> To: Noveck, David
> Cc: Haynes, Tom; nfsv4 list ([email-masked])
> Subject: Re: [nfsv4] Issue with section 3.2.5.1?
>
> On Wed, 2013-08-14 at 13:02 -0400, Noveck, David wrote:
>> I accept that it is possible things could be done this way.  But you need, among other things,
>>   o A new section about how the destination server constructs READ operations that it uses
>>      to implement the COPY, including how it recovers from the client of the COPY rebooting,
>>     and the source server rebooting.
>
> I accept that we might want to describe the READ operation. I'm assuming a very simple model that is similar to that used by pNFS clients to talk to the DSes, unless someone sees an objection.
> So the destination server sets up a session on the source server using 
> whatever clientid+authentication that it wants (including possibly the 
> SSV that was provided by the COPY_NOTIFY - although I'd prefer not to 
> have to do that). The destination server then uses a standard SEQUENCE
> +PUTFH+READ in combination with SSV GSS authentication to actually 
> +PUTFH+read
> the data from the file on the source.
>
> Reboot recovery is not an issue: the COPY operation halts on reboot of either server and also in the case where the client's lease expires.
>
>>  o A new version of the description of the *READ* operation that specifies how the source
>>      server is to distinguish these special on-behalf-of-COPY READ operations and then handle
>>      them.
>
> That's what the SSV is for. The _source_ server would provide the SSV, and therefore can use that to authenticate the READ operations. The SSV will actually tie the entire set of READ requests to the specific COPY_NOTIFY request.
>
>> In addition to having those things written as well as a bunch of 
>> ancillary addition and revisions, (volunteers anyone?), and getting 
>> consensus on the revised spec, I would not be confident about this 
>> until there was an actual implementation of inter-server copy that did this and my guess is that we won't see  that in Westford next month.
>
> I agree that an implementation is going to take a while. For one thing, I'm not aware of any existing implementations of SSVs or SSV GSS, despite their prominence in RFC5661.
>
> That said, I believe that this is a viable alternative to the
> RPCSEC_GSSv3 route, which, while appearing to suffer no lack of cheerleaders, has seen no volunteers for shepherding a spec through the IETF.
> It may therefore be worth considering for that reason.
>
>> This is sounding like something that will not make it into a 
>> draft-ietf-nfsv4-minorversion2-xx for any reasonable value of xx.
>
> Possibly, and in that case, we should probably defer inter-server copy to 4.3. I'd be OK with that solution, since it would not impact our current intra-server only Linux implementation.
>
> Cheers
>   Trond
>
>> -----Original Message-----
>> From: Myklebust, Trond [mailto:[email-masked]]
>> Sent: Wednesday, August 14, 2013 12:10 PM
>> To: Haynes, Tom
>> Cc: Noveck, David; nfsv4 list ([email-masked])
>> Subject: Re: [nfsv4] Issue with section 3.2.5.1?
>>
>> On Wed, 2013-08-14 at 15:59 +0000, Haynes, Tom wrote:
>> > On Aug 14, 2013, at 8:46 AM, "Myklebust, Trond" <[email-masked]> wrote:
>> >
>> > >> The basic issue is that, in v4.1, stateids (and lockowners and
>> > >> openowners) are implicitly qualified by the clientid associated 
>> > >> with the session that they are used on.  If the destination 
>> > >> server were to act as a client of the source server, and use one 
>> > >> of  these types of locking-based objects, it would have to 
>> > >> pretend to be another client (the one doing the COPY) leading to the kinds of lease management issues that Tom was concerned about.
>> > >
>> > > Right, but COPY_NOTIFY is telling the source server both which 
>> > > stateid that the destination server will use, as well as the 
>> > > network location associated with that server.
>> >
>> > It is possible for the destination to already be acting as a client 
>> > to the source, which means it has a client ID and possibly some existent stateids.
>> >
>> > What happens when the source gives the client a stateid CSA which 
>> > has the same bit pattern as an existent stateid the destination has with the source?
>>
>> See my response to Dave. I suggest having COPY_NOTIFY return an SSV for use by the destination server to tie the use of this stateid in GSS SSV-authenticated READ requests to this client (and you can even tie it to this specific COPY operation).
>>
>> --
>> Trond Myklebust
>> Linux NFS client maintainer
>>
>> NetApp
>> [email-masked]
>> www.netapp.com
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email-masked]
> www.netapp.com
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4