Subject: [nfsv4] NFS4.2 inter-server copy spec concern

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 26 Feb 2015 10:43:24 -0500

Hi folks,

I'd like to raise a concern that the current specification in COPY_NOTIFY
is insufficient (or maybe that it makes implementation unnecessary
complicated on the servers).

At the time of COPY_NOTIFY, the source server needs to remember
cna_src_stateid and match it to the corresponding READ request from the
destination server.

My first concern is about matching ips. At the time of COPY_NOTIFY, the
source server has the destination server ip provided by the client, using
the spec example say it's 203.0.113.56. Thus the source server can store
say cna_src_stateid=0xf00bar and cna_destination_server=203.0.113.56. Yet,
the READ can come from 192.0.2.56 which won't match any stored values. The
only thing that source server can check is that READ came from the same
subnet, 192.0.2.0/24 for which it included its ip of 192.0.2.18 in the
cnr_source_server list in the reply of COPY_NOTIFY. Thus, I don't see how's
possible to verify that READ request came from the destination server the
client specified in COPY_NOTIFY (unless it's mandated that the destination
server MUST use the same ip used with the client).

My second concern is regarding uniqueness of stateid. There is only a
guarantee of uniqueness of stateids for a clientid. Two different clientids
that open the same file can get the same stateid. Thus, if we have two
copies initiated from two different clientids, then the source server is
required to deal with non-uniqueness by either ref counting or allowing for
duplicates on the list. If gssv3 is used then we can use the generated
shared secret to provide us a lookup key for stateids to be matched.
However, spec allows for non-gssv3 implementation. Using user identity
(i.e., user@nfsdomain) as a key also doesn't seem to work because the
destination server will be making the READ as user@nfsdomain in gssv2.
Maybe ref counting or duplicate entries is a perfectly fine implementation
but seems like if we added a random_number to COPY_NOTIFY (as is suggested
for things like urls) it would make implementation must easier.

Thank you.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 27 Feb 2015 09:02:23 -0800

> On Feb 26, 2015, at 7:43 AM, Olga Kornievskaia <[email-masked]> wrote:
> 
> Hi folks,
> 
> I'd like to raise a concern that the current specification in COPY_NOTIFY is insufficient (or maybe that it makes implementation unnecessary complicated on the servers).
> 
> At the time of COPY_NOTIFY, the source server needs to remember cna_src_stateid and match it to the corresponding READ request from the destination server. 
> 
> My first concern is about matching ips. At the time of COPY_NOTIFY, the source server has the destination server ip provided by the client, using the spec example say it's 203.0.113.56. Thus the source server can store say cna_src_stateid=0xf00bar and cna_destination_server=203.0.113.56. Yet, the READ can come from 192.0.2.56 which won't match any stored values. The only thing that source server can check is that READ came from the same subnet, 192.0.2.0/24 <http://192.0.2.0/24> for which it included its ip of 192.0.2.18 in the cnr_source_server list in the reply of COPY_NOTIFY. Thus, I don't see how's possible to verify that READ request came from the destination server the client specified in COPY_NOTIFY (unless it's mandated that the destination server MUST use the same ip used with the client).

Look at Section 4.10.1.2:

   When the client sends the source server the COPY_NOTIFY operation,
   the source server may reply to the client with a list of target
   addresses, names, and/or URLs and assign them to the unique
   quadruple: <random number, source fh, user ID, destination address
   Y>.  If the destination uses one of these target netlocs to contact
   the source server, the source server will be able to uniquely
   identify the destination server, even if the destination server does
   not connect from the address specified by the client in COPY_NOTIFY.
   The level of assurance in this identification depends on the
   unpredictability, strength and secrecy of the random number.

I.e., in this case it is the “secret number” which authenticates the destination, even from a different IP than provided.

> 
> My second concern is regarding uniqueness of stateid. There is only a guarantee of uniqueness of stateids for a clientid. Two different clientids that open the same file can get the same stateid. Thus, if we have two copies initiated from two different clientids, then the source server is required to deal with non-uniqueness by either ref counting or allowing for duplicates on the list.

The concern is that the copies are from different clients, from the same source, and to the same destination? 

> If gssv3 is used then we can use the generated shared secret to provide us a lookup key for stateids to be matched. However, spec allows for non-gssv3 implementation. Using user identity (i.e., user@nfsdomain) as a key also doesn't seem to work because the destination server will be making the READ as user@nfsdomain in gssv2. Maybe ref counting or duplicate entries is a perfectly fine implementation but seems like if we added a random_number to COPY_NOTIFY (as is suggested for things like urls) it would make implementation must easier. 
> 
> Thank you.
> 

Why can’t the source use that random number it generated and gave to the client as a key? So the burden would be on the source to not generate the a random number already in use.