Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!uw-beaver!cornell!rochester!udel!gatech!purdue!decwrl!hplabs!sdcrdcf!csun!polyslo!dorourke From: dorourke@polyslo.UUCP Newsgroups: comp.protocols.appletalk Subject: Re: AppleTalk in large diverse networks Message-ID: <2521@polyslo.UUCP> Date: 12 May 88 18:31:12 GMT References: Reply-To: dorourke@polyslo.UUCP (David O'Rourke) Organization: Cal Poly State University -- San Luis Obispo Lines: 50 Posted: Thu May 12 14:31:12 1988 In article "L. Stuart Vance" writes: Some excellent idea's. All of the idea's expressed are very good. But in my opinion would complicate the simplicity and elegance of the Appletalk protocol suite. But I do realize the security problem and I also had to cope with it. I was involved in a project to bring Appletalk to a major Mainframe company and our implmentation had to deal with the problems of Appletalk security. We took a very simple approach, and basicly it simply requires more intelligent bridges. Appletalk says that every bridge on the network reports the names that that bridge knows about, but it doesn't say that all of the bridges have to be completly honest. Since most software uses NBP to find things, if it can't find a name then it's can't find the socket, so now you have effectivly removed access to that device for people in different zones. Also you can have the bridge check all internet traffic and if someone is triing to send information to a socket that the bridge hasn't published then it just doesn't let the packets through. This model is also easily extended so that the "active" bridge as we called it reports different sets of names depending on where the request came from, so that a Network administrator can allow select groups of people access while not allowing others. Also we are/will have implemented a scheme that allows the bridge to "collect" Laser Jobs and then at some time during the day someone can look at the jobs in the queue and determine what is allowed to go through. Sometimes it's convient to allow traffic to go through, for instance allow payroll to send a report to accounting by just having payroll print to accounting laserprinter, it's make a real nice way to "transfer" information thru the use of Apple's standard print drivers, and keeps the training time down to a minimum. I realize this isn't a perfect solution and requires some extensive hardware, but we found it works quite well, and we didn't have to modify the protocol to implement it. But I agree some modifications might be nice. But I fear it's too late in the game. I am open for comments, flames, whatever. Maybe in about 3 months I can tell you who the company is, we've done some neat stuff with it. I wish I could post it on the board. David M. O'Rourke +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | dorourke@polyslo | Disclaimer: All opinions in this message are mine, but | | | if you like them they can be yours too. | | | Besides I'm just a student so what do I | | | know! | |-----------------------------------------------------------------------------| | When you have to place a disclaimer in your mail you know it's a sign | | that there are TOO many Lawyer's. | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++