KDC query client performance

[Roland C. Dowdeswell]

On Mon, Feb 14, 2011 at 07:34:51PM -0500, Sam Hartman wrote:
>

> >>>>> "Simo" == Simo Sorce <ssorce at redhat.com> writes:
> 
>     Simo> On Mon, 14 Feb 2011 18:35:14 +0000
>     Simo> "Roland C. Dowdeswell" <elric at imrryr.org> wrote:
> 
> > Also, it might be a better idea in the longer term to write a little
>     >> daemon that runs as root, listens on a UNIX domain socket and
>     >> accepts requests from the krb5 libs to have conversations with
>     >> various KDCs.  The advantage of this would be that this daemon
>     >> could keep track of which KDCs are up and perhaps even keep track
>     >> of which ones answer the quickest (and are therefore likely the
>     >> closest), etc.
> 
>     Simo> You can do this separately by creating a locator plugin.
>     Simo> That's what we do with the SSSD project at least, so that the
>     Simo> sssd daemon does the discovery and just tells the krb5 libs
>     Simo> what is the ip address to use for the KDC.
> 
> Yes, but I think that this is important enough to Kerberos performance
> that someone should really do this separately from SSSD.  If you're
> going to use SSSD, or some full infrastructure, you'll use their KDC
> locator.  However, you really want this service.  All the time. Even if
> you just want a Kerberos client.

I was considering writing something quite cheezy for this at work
that supported UDP only.  It would just be a UDP relay more or less
with a little logic about who is responding and how fast with no
analysis of the contents of either the outgoing packets or the
replies.

This would have a couple of advantages:

	1.  you wouldn't need to understand the contents of UDP packets
	    at all, all you would need to do is time the responses
	    and keep track of which KDCs were responding and maintain
	    a bit of an algorithm to keep that fresh, and

	2.  it would require no client-side support at all, just put

		kdc = 127.0.0.1:88

	    in the realm section of /etc/krb5.conf and it would
	    work.  This was important when I was considering it
	    because I have to ensure that many different Kerberos
	    libraries and versions would work properly.  The main
	    culprit being the Java JGSS libraries whose failover
	    behavior really wants a little help of this sort.
	    Multiple realms could be supported by running UDP relays
	    on multiple ports.  One could also put the regular KDCs
	    after the ``kdc = localhost'' line which would provide
	    the assurance that if the proxy crashed, the clients
	    would behave almost identically to how they might have
	    if it hadn't been written.

Effectively, it would be equivalent to dynamically putting the most
responsive KDC at the head of the KDC list at all times.

That said, we didn't really have a performance issues and so it
wasn't considered to be a priority.  It was interesting to consider
for a while, though.

Doing it the cheezy way as described above, provides the advantage
that any Kerberos client library can use it, however it leaves lot
of the performance enhancements that could be achieved on the table.
If one took the approach of a UNIX domain socket with which the
clients have a more interesting conversation where they let the
proxy know what their intent is, then all sorts of things such as
the xrealm graph could be cached to avoid repeating the traversals
mentioned at the beginning of this thread.  Although, at that point
this would be more like a new ccache type that operates over a
local socket rather than a simple KDC proxy.

There is a large advantage to be had from keeping a little bit of
states on the client hosts which can be shared amongst the various
client applications especially if said state is [safely] shared
between users.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/