From: Mike Eisler (mike@eisler.com)
Date: 12/20/02-12:22:24 PM Z
Message-ID: <3E035FE0.20102@eisler.com>
Date: Fri, 20 Dec 2002 10:22:24 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt
Brent Callaghan wrote:
>
> Robert Thurlow wrote:
>
>>> The design refers to the efficiency issue. It says you don't want
>>> to send lots of small packets and I agree. I think the
>>> messages as they are now constructed don't lend themselves
>>> very well to simply being transposed to rpc's. In fact I would
>>> argue that they have some efficiency problems even in the non-RPC
>>> model (security token on every piece). So I think you need a send
>>> RPC that allows you send a whole buffer of the tiny
>>> data items that you now have as RPC's.
>>
>>
>>
>> I'd considered just saying, "use IPSec" to solve security.
>> I chose not to do so because I knew several implementors
>> who will have more experience with GSS-API/RPCSEC_GSS style
>> security, and wondered if all vendors had IPSec available
>> to their purposes. If we go to RPC and don't turn back,
>> this is moot, but I had wanted to have the discussion about
>> what style of security was going to be better.
>
>
>
> My impression of a replication/migration protocol is that it's
> not a transactional protocol, like file access, but a flow
For the most part the data transfer protocol is not transactional, but there
are lots of exceptions:
- session creation
- session resumption
- check pointing
- session termination/aborting
And the current strawman is specified to have a return message for
every request message, which I've already complained about; the SEND_*
messages should be flows, not transactions.
> of deltas. It doesn't make sense to divide up the flow into
> arbitrary RPC messages. RPC doesn't add much value here.
We are going divide to the flow into something though. What's the
qualitative difference between dividing it up into a some unspecified
something, or something that is well specified (ONC RPC), and
has no return calls? This has been done for years with the
NLM protocol.
>
> If it's a flow based protocol, then it makes sense to apply
> security to the flow as a whole - not individually to the
> deltas within it. For instance, if you're pushing deltas
> from one system to another, the credentials of the processes
> that made the changes are long gone. The only credential of
> interest is that of the "superuser" or user authorized to
> effect the changes. I recommend the stream be secured.
> There's already a wide choice of suitable methods, TLS,
> IPsec, SSH etc.
Another argument I've heard in this thread against RPC, or rather sending
lots of little RPC requests versus a single big one is
per RPC request overhead. A cursory examination of
TLS, IPsec, SSH, etc. will reveal that they too break the stream
into chunks (think it through ... how practical is it to perform an
integrity/encryption operation on the entire stream, especially when
you might not know in advance the length of the stream?)
and so they too have their overheads. If one is
concerned about per request overhead, then IPsec is a
lousy choice, since the overhead is per physical packet.
The advantage of IPsec is that there are off the shelf hardware
assists for it. But IPsec is essentially host-based authentication,
and we would still need user to user authentication for this protocol.
TLS doesn't really have it unless you are using user certificates,
or Kerberos authentication. Instead, http over TLS relies on
password authentication ... so user authentication is practically
speaking, outside TLS.
The issues of NFS over fast media and some analysis of
trends in processor speed versus network medium speak
have made me realize that even simple RPCSEC_GSS authentication
is going to be costly for really fast media. Obviously these
issues apply even more so to the data transfer protocol.
I've had some thoughts about what we could do about it NFSv4,
without compromising strong end-user
authentication, but the solutions are applicable to
transfer protocol. I'll send my thoughts in a separate message/thread.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:44 AM Z CST