[233] in Zephyr Mailing List
Re: Interrealm support issues
daemon@ATHENA.MIT.EDU (Derek Atkins)
Wed Jan 1 11:03:44 1997
To: Greg Hudson <ghudson@MIT.EDU>
Cc: zephyr@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 01 Jan 1997 11:01:33 -0500
In-Reply-To: Greg Hudson's message of Wed, 1 Jan 1997 05:42:25 -0500
First, just to clarify a point, when I implemented multi-realm zephyr
about 7 years ago (yes, it was that long ago!) I wanted to make as few
changes as possible. I only needed to change zhm (to talk to various
realms) and zctl (to subscribe to remote realms). Other clients only
needed to be modified to send authentic messages. I didn't want to
change the protocol, since that would have required a lot more work
(and 7 years ago I really didn't understand how to do that ;).
There are advantages to both systems. The nice thing about my way is
that you don't have the administrative hastle of setting up
cross-realm zephyr support. However the amount of network traffic is
potentially created is high.
On the other hand, you need to set up a shared kerberos key, which
requires some amount of administrative overhead. So, you could
theoretically set up the zephyr administrative work at the same time
(presuming the same people maintain both services).
One feature of my system is that the client does not need to trust the
local realm to deliver messages to remote recipients. The client
talks directly to the remote realm. For sending messages, in
particular personal messages, I think this is a better mechanism.
This way the client can truly authenticate to the server, rather than
performing proxy authentication.
For receiving messages, however, it works best to recieive from the
local realm. This reduces the amount of cross-realm traffic.
So, perhaps an appropriate model is that you send directly to the
destination realm, when possible. If the client doesn't know about a
remote realm, it sends to the local realm (who can forward it on).
The only question I have is about subscriptions. I think it's cleaner
to have the client send the subscription to the remote server, but for
broadcast messages the remote server should only need to send one copy
to the local realm for distribution locally....
One thing I'd like to see is symmetric communications (vs the
asymmetric communications we have now). This way either *everything*
goes through the hostmanager, both incoming and outgoing. It would
make zephyr through firewalls a lot easier!
I don't think I added anything here, I'm pretty much just rambling.
But here are my thoughts.
-derek
Greg Hudson <ghudson@MIT.EDU> writes:
>
> 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.
--
Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
Home page: http://www.mit.edu:8001/people/warlord/home_page.html
warlord@MIT.EDU PP-ASEL N1NWH PGP key available
