Re: [nfsv4] NFSv4.2 draft inter server copy correction

[Chuck Lever <[e-mail]>]

On Mar 3, 2015, at 2:11 PM, Tom Haynes <[e-mail]> wrote:

> 
>> On Mar 3, 2015, at 10:38 AM, Andy Adamson <[e-mail]> wrote:
>> 
>> On Tue, Mar 3, 2015 at 12:56 PM, Tom Haynes
>> <[e-mail]> wrote:
>>> 
>>>> On Mar 2, 2015, at 6:47 AM, Adamson, Andy <[e-mail]> wrote:
>>>> 
>>>> 
>>>>> On Feb 28, 2015, at 5:56 AM, David Noveck <[e-mail]> wrote:
>>>>> 
>>>>>> I don’t think we want to do an OPEN  from the destination server, because we already have an open stateid, and doing an OPEN from the destination
>>>>>> server will conflict with: [4.4.1]
>>>>> 
>>>>> True but the way 4.4.1 is written, it is not clear that where will always be an OPEN e.g. "may need", "can achieve", "might be desired”.
>>>> 
>>>> The whole point of passing the source stateid and file handle is to obviate the need for an OPEN from the destination server, and totally avoid the issues of a share or byterange lock on the OPEN’s from the client.  If the destination server is implemented to use the compound with the OPEN in Section 4.10.1.2, then when the OPENs issued by the client do have a conflicting share or byte-range lock, the copy will fail. Since there is no reason for the OPEN/GETFH, I say remove it.
>>>> 
>>> 
>>> 
>>> This section details how the destination can authenticate.
>> 
>> OK. Some questions. From the spec:
>> 
>>   The client will then send these URLs to the destination server in the
>>   COPY operation.  Suppose that the 192.0.2.0/24 network is a high
>>   speed network and the destination server decides to transfer the file
>>   over this network.  If the destination contacts the source server
>>   from 192.0.2.56 over this network using NFSv4.1, it does the
>>   following:
>> 
>>   COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
>>      "FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
>> 
>>     ^^^^^^^^^^^^^^
>> (Why is a 203.0.113 address being used over the 192.0.2. network?)
> 
> This was a question Olga asked last week?  
> 
> In a multi-homed
>    environment, the destination server might not contact the source
>    server from the same network address specified by the client in the
>    COPY_NOTIFY.  This can be overcome using the procedure described
>    below.
> 
> ..
> 
> Look at the available URLs:
> 
>       nfs://203.0.113.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/
>       _FH/0x12345
> 
>       nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/
>       0x12345

NFS URIs are defined in the FedFS NSDB protocol doc. Do these
URLs conform to that specification, or does NFSv4.2 construct
NFS URLs differently?

See

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/?include_text=1

Section 2.8.1.

> Each of the components is part of the tuple which describes allowed access.
> 
> By presenting each of them within the compound, the destination is
> authenticating itself to the source.
> 
> 
> 
>> 
>>      OPEN "0x12345" ; GETFH }
>> 
>> If you are doing an OPEN CLAIM_FH, why do you need a GETFH?
>> 
>> I'm guessing that the idea here is that the OPEN by file handle in the
>> URL using the file handle from the SAVE_FH in the COPY compound (e.g.
>> the file handle from the OPEN to the source server by the client) in
>> this URL will return an "authenticated file handle" in GETFH that the
>> destination server can then use for the copy READ and this makes it
>> 'authenticated'? I'm guessing, because there is no mention of this in
>> the spec. Also not mentioned is which stateid a READ from the
>> destination server will use. The ca_src_stateid or the stateid
>> returned by the OPEN in the above URL?
>> 
>>   Provided that the random number is unpredictable and has been kept
>>   secret by the parties involved, the source server will therefore know
>>   that these NFSv4.x operations are being issued by the destination
>>   server identified in the COPY_NOTIFY.  This random number technique
>>   only provides initial authentication of the destination server, and
>>   cannot defend against man-in-the-middle attacks after authentication
>>   or an eavesdropper that observes the random number on the wire.
>>   Other secure communication techniques (e.g., IPsec) are necessary to
>>   block these attacks.
>> 
>>> 
>>> So if the destination server uses the FH directly, then the random number is useless since it will never be called.
>> 
>> Why not get rid of the OPEN/GETFH in the URL and replace it with the
>> PUTFH"0x12345"/READ "ca_src_stateid' that you actually want? Then
>> authentication occurs as the random number is presented, then there is
>> no OPEN for the source server to treat in a special way.
>> 
> 
> 
> I think the confusion here is that the suggested approach is just one
> implementation approach that could be taken, especially if someone
> wants to use the pseudo-random number mumbo-jumbo to fake
> themselves into thinking there has been no man-in-the-middle attack.
> 
> Another perfectly valid approach is to throw Section 4.10.1.2. out and
> just use OPEN CLAIM_FH. If the source doesn’t allow access, then
> try getting a FH with the mumbo-jumbo.
> 
> 
> 
> 
>>> 
>>> And, the source is supposed to understand that it must not fail the copy for the destination opening the file even in the
>>> presence of a conflicting share and/or byte-range lock.
>>> You can ask how the client is supposed to differentiate between
>>> the destination opening the file for some other user versus this COPY and the answer is by processing the path
>>> given by the URL.
>>> 
>>> 
>>> 
>>>> —>Andy
>>>> 
>>>>> On Fri, Feb 27, 2015 at 2:50 PM, Adamson, Andy <[e-mail]> wrote:
>>>>> Hi Tom
>>>>> 
>>>>> in 4.10.1.2.  Inter-Server Copy via ONC RPC without RPCSEC_GSS:
>>>>> 
>>>>>  The client will then send these URLs to the destination server in the
>>>>>  COPY operation.  Suppose that the 192.0.2.0/24 network is a high
>>>>>  speed network and the destination server decides to transfer the file
>>>>>  over this network.  If the destination contacts the source server
>>>>>  from 192.0.2.56 over this network using NFSv4.1, it does the
>>>>>  following:
>>>>> 
>>>>>  COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
>>>>>     "FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
>>>>>     OPEN "0x12345" ; GETFH }
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 
>>>>> I don’t think we want to do an OPEN  from the destination server, because we already have an open stateid, and doing an OPEN from the destination server will conflict with:
>>>>> 
>>>>> 4.4.1.  Locking the Files
>>>>> 
>>>>> 
>>>>>  Both the source and destination file may need to be locked to protect
>>>>>  the content during the copy operations.  A client can achieve this by
>>>>>  a combination of OPEN and LOCK operations.  I.e., either share or
>>>>>  byte range locks might be desired.
>>>>> 
>>>>> 
>>>>> I also think the GETFH is not needed, as the COPY compound has the SAVE_FH which provides the FH of the file to READ.
>>>>> 
>>>>> —>Andy
>>>>> _______________________________________________
>>>>> nfsv4 mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com