[4948] in Kerberos
Re: Kerberos requirements (was Re: SATAN, Dan Farmer, SGI, security, etc.)
daemon@ATHENA.MIT.EDU (Joe Kovara)
Sat Apr 8 21:13:06 1995
To: kerberos@MIT.EDU
Date: Sat, 8 Apr 1995 17:07:36 -0700
From: Joe Kovara <joek@kerby.ocsg.com>
On 5 Apr 1995, Larry J. Hughes Jr. wrote:
> In article <3lp1s1$dos@kei.com>, Christopher Davis <ckd@loiosh.kei.com> wrote:
> >Got any Sun3s around? Maybe an old 386? Kerberos KDCs are not *that*
> >CPU-hungry, after all. A 386 running BSD/OS or FreeBSD or something
> >should work just fine, and you can probably pick one up for free from
> >some secretary's desk when it's replaced with a 486 or Pentium. Depending
> >on your site's upgrade cycle, you may be able to get several of them for
> >redundancy (slave servers).
I don't have any numbers for MIT's code, but to give you an idea of
the kind of resources a KDC consumes...
Our (CyberSAFE's) KDC running on a 486/66 OS/2 system with unoptimized
code (IBM's CSET compiler) turns around an AS-REQ in 26ms. CPU time. (and
no, that is not the time for a cached response--that's start to finish for
decoding/decrypting/lookup/encoding/encrypting). Optimization drops it by
30-40%. Why this configuration? It's pretty much a lower bound on
performance :-) Obviously you need to add database I/O time and network
overhead Database I/O time will vary tremendously depending on what
package you are using, level of caching, distribution of requests, etc.
(I'll simply note that a mulit-threaded/multi-process implementation helps
alleviate some of these potential I/O bottlenecks)..
Please note that these numbers are based on an implementation which is
completely different from MIT's; I can only guess at what it might be
for the MIT release, but past experience indicates a 4-5x multiplier
(their's slower) is not unusual. However, even at that, a 486/66
running MIT's code should still be capable of handling 8-10 AS-REQ's/sec.
I would think that this would be more than sufficient for any site that
isn't large enough to justify more horsepower.
> Old machines like Sun3s and even Vaxstations can serve up tickets just
> fine, but if you try to set up slave systems and you have a sizeable
> database, forget it. I did this for a while and when our database
> grew past 20,000 users (as it will for many .edu sites) it was taking
> more than 2 hours for the dump-prop-reload hack to happen. It's
> nearly impossible to keep the slaves in sync with the master.
Only a problem if you don't have incremental database propagation ;-)
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
