From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 12/20/02-01:15:11 PM Z
Date: Fri, 20 Dec 2002 11:15:11 -0800 From: Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt Message-ID: <20021220111509.G1041@binky.central.sun.com> If the issue is encoding efficiency and there aren't going to be lots of octet streams per packet then PER is probably the best encoding. But a migration protocol will likely involve sending large numbers of large data chunks with fairly little header overhead, so that the inefficiency of XDR as an encoding will hardly matter. As Mike Eisler points out, the crypto overhead will be pretty hefty already, so will the encoding overhead be significant? (As long as XML is not used I'd say "no" :) If the efficiency of XDR does turn out to be an issue, couldn't the encoding be changed later? Switching to PER would involve using ASN.1 instead of ONC RPC, of course, but the structure of the types might not change much... I rather suspect that noone in this WG will want to use ASN.1/PER though :) , so that leaves ONC RPC/XDR and what else? SSHv2 or TLS encodings? As for RPCSEC_GSS performance, it may be possible to use a single context to provide integrity/privacy for an entire stream, at the stream level, with each operation referencing a GSS context handle for authorization on the server side. No? Cheers, Nico On Fri, Dec 20, 2002 at 10:22:24AM -0800, Mike Eisler wrote: > 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