[232] in Zephyr Mailing List
Interrealm support issues
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jan 1 05:46:15 1997
Date: Wed, 1 Jan 1997 05:42:25 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: zephyr@MIT.EDU
The major planned new feature in Zephyr 2.1 is interrealm support.
There are two major approaches to interrealm support, and I'd like to
get feedback from the list on how people would like to see it done.
The first approach is the client-side approach originally done by
Derek Atkins (and redone very recently by Marc Horowitz in a somewhat
different way). In Derek's approach, the host manager dispatches
notices to different realms according to the Kerberos realm of the
recipient. (Marc adds a new field to the notice and modifies the
protocol between the client library and the host manager, which is
somewhat cleaner.) The major drawback of the client-side approach is
that long-distance network traffic scales according to the number of
remote subscribers of a triplet.
The second approach is the one originally done at CMU. In the CMU
model, a host manager talks to only one realm (as in the Zephyr 2.0
code) and the server dispatches notices to servers in remote realms
based on the Kerberos realms of recipients. Long-distance network
traffic scales according to the number of remote realms subscribing to
a triplet, not the total number of subscribers.
I already integrated the CMU code into Zephyr (it's in 2.1 beta ,
although 2.1 beta 1 has many bugs) on the basis of improved scaling.
However, lately I've been having a few misgivings about the CMU
approach:
* There is a trust issue. If I run the MIT zephyr realm,
I have to trust the CMU zephyr realm to send a message to
the person I direct it at, instead of to someone else.
However, it's worth noting that in both models, I have to
trust the CMU Kerberos realm not to give away keys to
unauthorized people, so at the moment I'm inclined to
disregard trust issues.
* In the CMU model, servers talk to each other, which
potentially creates a maintenance problem. If servers never
talk to each other (as is the case in, say, AFS), it becomes
impossible for poor administration in one realm to affect
servers in another realm. I don't know if there are any
real practical issues involved in the CMU implementation,
though.
* Hijacking the recipient Kerberos realm to determine the
Zephyr realm is really pretty unclean; nobody tries to
equate AFS realms with Kerberos realms, and doing it in
Zephyr bothers me. If you do inter-realm on the client
side, it's a little easier to add a "realm" field to the
local-machine protocol because you can assume a little more
about whether the client library and host manager are in
sync.
* Doing it in the client allows people to experiment with it
without upgrading production servers. I'm probably going to
disregard this issue because it's transitionary.
A few people have argued that Zephyr should support both mechanisms,
but I think that would create too much of a mess.
Comments? After hashing it out, it looks like the protocol
cleanliness issue is the biggest problem I have with the CMU approach,
and perhaps I should just try to find a path to a cleaner protocol for
server-side interrealm support.
