Re: server-side copy offload I-D

Comments inline, prefixed by Rahul>

-----Original Message-----
From: Tom Haynes [mailto:Thomas.Haynes <at> Sun.COM] 
Sent: Friday, April 03, 2009 10:25 AM
To: Madan, Anshul
Cc: nfsv4 <at> ietf.org
Subject: Re: [nfsv4] server-side copy offload I-D

anshul wrote:
> On Fri, 2009-04-03 at 01:04 -0500, Tom Haynes wrote:
>   
>> Mike Eisler wrote:
>>     
>>> On Thu, April 2, 2009 3:03 pm, Nicolas Williams wrote:
>>>   
>>>
>>>       
>>>> Why would it be a configuration error to have a private network 
>>>> between the servers?
>>>>     
>>>>         
>>> Good point.
>>>
>>> It seems to me that if the destination address is different behind 
>>> glass, so in the source address. COPY_NOTICE could return the source

>>> address that should be used. The COPY operation would then include 
>>> that source address. By virtue of RPCSEC_GSSv3 privilege, the 
>>> destination will have proven to the source that it is the server 
>>> authorized to read on behalf of the user.
>>>
>>>   
>>>       
>> The client presents in the COPY_NOTICE 10.10.20.42 as the address of 
>> the destination server.
>> Or perhaps it presents foo.corp.company.com.
>>
>> How does the source server know what the backend name/IP is for the 
>> destination server?
>>     
>
> Why does it need to? The server-to-server protocol can present
> 10.10.20.42 to the source server even if the destination server 
> communicates with the source server from a different IP say 1.2.3.4.
>
>   

But how does the destination server know to communicate with the source
server at 10.100.10.42?

Look at the following:

               +------- 10.100.10/24 -------------+
               |                                  |
               | 10.100.10.43                     | 10.100.10.42
          +----+---+                       +------+------+
          | Source |                       | Destination |
          +----+---+                       +------+------+
               | 10.10.20.43                      | 10.10.20.42
               |                                  |
               |                                  |
-- Glass Wall  | -------------------------------- | ----------------
               |                                  |
               |                                  |
               +------- 10.10.20/24 -+------------+
                                     |
                                     |
                                     |
                                     | 10.10.20.192
                                +----+-----+
                                | Client   |
                                +----------+

Assume 10.100.10/24 is a 10G network and 10.10.20/24 is a 1G network.

The client sends a COPY_NOTIFY to the source. It sends it to
10.10.20.43, because it has no idea of 10.100.10.43 and can't even talk
to that address. It states to expect a COPY request from 10.10.20.42.

It then sends a COPY to the destination at 10.10.20.42. It states that
the copy is to occur with 10.10.20.43.

How does the destination know that 10.10.20.43 corresponds to
10.100.10.43?
And while I've lined the numbers up, you can't count on that always
happening. And in any event, how does the kernel know this?

The proposed change here is that the COPY_NOTIFY returns to the client
the list
of:

10.10.20.43
10.100.10.43

And the client in turn sends that on in the COPY.

Now the destination sees that it can talk to source at either of the two
addresses. And seeing as how it has interfaces on both of those, it can
chose either. 
We would just
prefer that it uses 10.100.10/24.

For some reason, I'm thinking an implementation would want some form of
a simple policy engine here to make that type of decision. :->

Really, the load might change during the time of day, we might want to
detect that one of the networks is down (or an interface to that network
is down), etc.

But in the terms of the protocol, we don't care which of the offered up
addresses is used.

Rahul> This sounds reasonable.

>> The COPY_NOTICE has to return a list of allowed source addresses. And

>> then the destination
>> server has to decide which one to use.
>>
>> An implementation might provide some means to allow the admin to 
>> configure the preferred networks
>> for server-to-server copies...
>>
>> But in the context of the proposal, any valid path selected by the 
>> destination should be accepted
>> by the source via the virtue of RPCSEC_GSSv3.
>>     
>
>
> Even when using AUTH_SYS, any valid path selected by the destination
> should be accepted by the source. RPCSEC_GSSv3 privilege allows the
> server to prove that it is the authorized to read from the source.
>
>   

But even if valid, with AUTH_SYS, we don't know that it is authorized.

Rahul> In traditional AUTH_SYS deployments, the server pretty much
accepts whatever user id the client offers up (root included, depending
on root_squash). That's the current model. Using a similar analogy, if
the source server has a COPY_NOTIFY for the destination, then it should
accept the copy offload request. It doesn't seem any weaker to me. If
the client indeed did want to read data belonging to other users, it
could just as easily do it without jumping through all the offload
hoops. With weak security like AUTH_SYS, why isn't the existence of a
COPY_NOTIFY at the source not sufficient authorization?
Thanks,
Rahul

> Regards,
> Anshul
>
>   
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>     
>
>   

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4