From: Mike Eisler (mike@eisler.com)
Date: 12/20/02-05:26:30 PM Z
Message-ID: <3E03A726.1050704@eisler.com>
Date: Fri, 20 Dec 2002 15:26:30 -0800
From: Mike Eisler <mike@eisler.com>
Subject: crypto performance and RPCSEC_GSS
RPCSEC_GSS was conceived with at least two
assumptions:
- connection time only authentication just isn't good enough.
First, RPCSEC_GSS may not be running over a transport that has
connections, and second, hijacking of TCP connections was even in
those days a well developed craft.
- host-based authentication, such as what one gets from
IPsec, is not good enough, because it does nothing to
cure the obvious security exposures of AUTH_SYS.
So RPCSEC_GSS continued the tradition of AUTH_DH
(AUTH_DES), and offered per RPC authentication, as well
integrity and privacy to protect the payload.
There are costs to per-message security though.
Several years ago I did some measurements.
See
http://www.connectathon.org/talks99/mre.pdf
slides 9 and 10. In summary, using 270 Mhz ultra sparcs,
100baseT, straight krb5 (no integrity, no privacy),
software crypto cost an additional 1% of CPU, and degraded throughput
(relative to AUTH_SYS), by 2.6%. So, if we had a medium
100X faster, then it would be 100% of the CPU, and degradation
of 260%. I don't think the hardware I worked with in 1999
is indicative of what I could have achieved with Sun's highest
end gear, and in any case, Sun's best stuff (according to
http://www.spec.org/cpu2000/results/res2002q4/ is
half the speed of Intel's and AMD's best). Let's
say that today one could find CPUs 20X
faster then what I tested with in 1999. So
on 10G media, I'm projecting a 5% CPU cost for
basic authentication, and a throughput degradation of 13%.
Moore's law will of course improve this, but if
we assume that network media speeds will continue to
improve at a rate better than Moore's law, we have
to consider other approaches ... we will hit a wall
eventually.
It has been observed (by Nicholas Williams today for example,
and I believe this is the assumption of the DAFS protocol)
that if you believe the network connection is secure, then
authenticating the user once, rather than every message, is
sufficiently secure. Various people have different opinions on
what it means to secure the connection. Personally, I think
means applying cryto to every byte at a level below RPCSEC_GSS.
But if this is done in software, one is no better off than with
RPCSEC_GSS integrity and privacy. So it would need to be done
in hardware, and practically speaking, it is at the IP/IPsec
level that hardware crypto for streams is getting the most
attention.
So what does this mean for the wg's current portfolio of
upper layer protocols? For NFSv4, I observe (actually
Dave Noveck did in a private email, but I'm taking
it a step further than Dave)the following. Assume the
NFSv4 server can detect that IPsec is being applied to
the data stream (presumably there, or could be, APIs
to indicate this).After a particular principal has authenticated
once with RPCSEC_GSS over kerberos or spkm, or any other secure
mechanism, it could then return WRONGSEC on subsequent accesses by that
principal in order to get it to downgrade security to a flavor that is
less CPU intensive. The lightweight flavor could be AUTH_SYS or it could be
a new, simple mechanism (under the GSS-API)
that simply has the NFSv4 string-based uid as an identifier.
Given that AUTH_SYS doesn't offer a global uid space,
a string-based flavor might be better. I would think that if the wg
pursues NFS on RDDP, we'd want to this new, lightweight flavor.
Note that no protocol changes to NFSv4 are required.
For the replication/migration protocol, we don't even
need the lightweight "name" mechanism. Since
we appear to have reached consensus that there will be just one session
per transport connection, then at session creation time we would use
a secure mechanism that identifies the source and target,
and, if the target believes the connection to be secure,
negotiate down to AUTH_NONE. We might as well use something
resembling SECINFO.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST