[1384] in Kerberos_V5_Development
Re: "benchmark" numbers not so bad after all
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Jul 13 16:53:52 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krbdev@MIT.EDU, kerberos-dev@cygnus.com
From: Ken Raeburn <raeburn@cygnus.com>
Date: 13 Jul 1996 16:52:38 -0400
In-Reply-To: "Theodore Y. Ts'o"'s message of Wed, 3 Jul 1996 14:51:17 -0400
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> A couple of comments on the speed up issues. First of all, it's really
> obvious the replay cache should be elimiated ---- as long as we have the
> lookaside cache, the replay cache is guaranteed _not_ to provide any
> benefit whatsoever. And, the replay cache is taking up 50% of the raw
> processing time of the ticket.
Something occurred to me yesterday: If our ASN.1 decoder is not
enforcing the Distinguished Encoding Rules (and at a glance I would
say it is not), an attacker should be able to send multiple requests
with the same data content but differing encoding. In that case, the
lookaside cache is useless (because it compares the wire encoding),
but the replay cache would catch it. So it would be the far more
expensive replay cache that would be the real defense against this
supposed known-plaintext attack. Am I missing something?
Given Ted's comments on the number of responses needed for realistic
attacks, and the performance impact of the rcache, I'm still inclined
to do away with it. If we really need it, let's use a memory-based
one. And maybe somebody gets by it -- once -- if their attack
coincides with the KDC getting restarted; no big deal.
And without the rcache, we have no real use for the lookaside cache.
(We can't get rid of the lookaside cache if we keep the rcache though.)
> So even without the replay cache removal, the capability of handling 23
> requests per second is about an order of magnitude more capacity than a
> site the size of MIT would need. Even if a company was doing something
> that used kerberos and WWW, it wouldn't significantly increase the load
> on the KDC since tickets are cached.
Richard, do you have any numbers on what peak demand is like at your
site?
If anyone has a script for cooking the log files and producing stats,
I'd like to get a copy. It would be interesting to ship with
Kerberos. Would also be useful to include in a posting to
c.p.kerberos asking for stats from other sites.
