xxss520@CHPC.BRC.UTEXAS.EDU ("L. Stuart Vance") (05/12/88)
As many of you already are aware, the current boom in the EtherTalk product
market has brought to the forefront two significant shortcomings of AppleTalk:
the limited number of hosts on a network, and the lack of security across
network boundaries.
I do realize that the developers AppleTalk never envisioned that it would be
as widely used as it is today. This, however, is not a valid excuse for not
NOW addressing the limitations of an 8-bit host address space. Being limited
to 254 active AppleTalk hosts on an Ethernet is becoming not only an
inconvenience, but a severe problem for large organizations such as the
University of Texas.
The greater problem that I am faced with now, however, is one of network
security. When dealing in an environment where multiple (dozens) different
organizations (departments) are using AppleTalk routers to interconnect their
LocalTalk networks over the same Ethernet, the difficulty quickly becomes
evident. Most of you in university environments realize that staff in the
Zoology department don't really want people in the Law School to be able to
access their file servers or print on their laser (or other) printers. And,
while you can (in most cases) password protect file servers, there is no
practical way to protect printers.
Now, some might suggest that we force departments to use private Ethernets to
interconnect their LocalTalk networks. This purist approach is impractical
(not to mention unenforceable), as some departments are scattered across
several buildings which are distant from each other, where the broadband cable
(Ethernet) system provides the only affordable means of connectivity. Also,
many departments use NCSA Telnet for local and Internet TCP/IP access, which
requires access to the campus Ethernet. Others might suggest that we assign
multiple AppleTalk network numbers to the Ethernet, one number for each group
of routers people wish associated with each other, thus partitioning the
departmental networks from each other. In point of fact, this is how we are
currently handling the problem. This solution breaks down, unfortunately, as
soon as someone attaches a Macintosh directly to the Ethernet. When the Mac
boots, it first establishes its host address and then sends out a broadcast
packet asking any available routers to tell it what network it's attached to.
Thirty routers respond with fifteen different network numbers, and the Mac joins
the network of whichever router responded most quickly. Also, given that
Kinetics' FastPath routers currently have no configuration password capability,
enforcement of network number assignments can be difficult.
My suggestions to Apple and the various router manufacturers are as follows:
(1) Increase the host number address space from 8 bits to (at least) 16 bits.
(2) Establish a standard for network (or zone) security based on something like
the following:
(a) Implement password protection of router parameters to enforce centrally
assigned network numbers.
(b) Network (zone) passwords should be specified by Mac users from within
the Chooser. A password field, possibly encrypted somehow, should be
added to the AppleTalk packet format, with the proper user supplied
password (for a given destination network or zone) placed in all
outbound packets.
(c) Implement a variety of options for network (zone) security: allow any
access with or without a password; allow access to users on a specific
list of networks (zones) with or without a password; disallow access to
users on specific networks (zones); disallow all external AppleTalk
access (allow only IP access). Each packet a router receives destined
for one of the networks the router is connected to should be examined.
If the password set in the packet matches the password assigned to the
network (zone), forward the packet. Otherwise issue a NAK of some kind.
If a packet is destined for a network not directly connected to the
router, forward the packet automatically.
Note that if passwords for all the networks in a given zone are set the same,
the concept of zone passwords may be used (which is significantly more intuitive
to the naive user than network passwords).
Comments? Flames? I make no claim that the above is the best way of handling
the problems. There may, in fact, be no best way. The simple fact is that
some solution must be found, since AppleTalk networks will continue to get
larger and more "organizationally heterogeneous". And, if anyone has developed
workarounds better than those we are using, I would definitely like to talk to
them. And, finally, I would really like to hear something from the folks at
Apple, Kinetics, etc...
Thanks,
L. Stuart Vance
Network Systems Specialist
University of Texas System Office of Telecommunication Services
THEnet: UTCHPC::XXSS520 BITNET: XXSS520@UTCHPC
Internet: XXSS520@CHPC.BRC.UTEXAS.EDU Ma Bell: (512) 471-2416
------dorourke@polyslo.UUCP (05/12/88)
In article <Added.8WWB2jy00Ui3IbeU9m@andrew.cmu.edu> "L. Stuart Vance" <xxss520@chpc.brc.utexas.edu> 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. | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jeff@tc.fluke.COM (Jeff Stearns) (05/14/88)
In article <Added.8WWB2jy00Ui3IbeU9m@andrew.cmu.edu>, xxss520@CHPC.BRC.UTEXAS.EDU ("L. Stuart Vance") writes: > As many of you already are aware, the current boom in the EtherTalk product > market has brought to the forefront two significant shortcomings of AppleTalk: > the limited number of hosts on a network, and the lack of security across > network boundaries. ... It's commonly stated that there is a limit of 254 hosts on an AppleTalk network, but we should recall that the actual limit is generally worse: 127 user nodes 127 server nodes Now allow me to include a third drawback, and then pose the Big Question... AppleTalk protocols have another undesirable trait, probably also a result of their "small-network" heritage: They depend heavily upon broadcast packets when acquiring a nodeID and when locating other network entities via the Name Binding Protocol. This may be tolerable in the LocalTalk universe where small networks are the norm. But running the AppleTalk protocols on EtherTalk looks ominous. Consider: a MINIMUM of 20 broadcast packets when acquiring a nodeID at reboot time. (Reading of the AcquireAddress() alogrithm in Inside AppleTalk suggests that things may be much worse in practice; there is NO upper bound on the number of broadcast packets emitted when nearly 127 user nodes are already in use.) Now the Big Question: I have an extended Ethernet of moderate size: five bridged segments supporting about 100 computers running TCP/IP. In the wings, several hundred PC's and Macintoshes awaiting connection, eager to run TOPS or AppleShare. What's going to happen when I try to connect, say, two hundred micros speaking EtherTalk? For starters, do I have to create several separate AppleTalk networks, just to handle the puny 127-node limit? (How do I do this on one extended LAN?) My Ethernet is bridged with DEC LAN Bridges, so broadcasts sail right through to all segments. Am I going to regret this? Am I going to regret EtherTalk, period? I'd especially love to hear from those of you who have EtherTalk networks in place. Respond by mail or news, as you see fit. Thanks! -- Jeff Stearns Domain: jeff@tc.fluke.COM Voice: +1 206 356 5064 If you must: {uw-beaver,microsoft,sun}!fluke!jeff USPS: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206
deering@PESCADERO.STANFORD.EDU (Steve Deering) (05/15/88)
Any possibility of getting Apple to specify an Ethernet *multicast* address, rather than the broadcast address, for Appletalk broadcasts? That would at least allow non-Appletalk systems to protect themselves from the interrupt load of all those gratuitous broadcasts. Steve Deering
morgan@JESSICA.STANFORD.EDU (05/17/88)
> Any possibility of getting Apple to specify an Ethernet *multicast* > address, rather than the broadcast address, for Appletalk broadcasts? > That would at least allow non-Appletalk systems to protect themselves > from the interrupt load of all those gratuitous broadcasts. We suggested this recently to some AppleTalk people at Apple. They admitted that RTMP broadcasts are a problem on a large net (though they didn't think the address-acquisition broadcasts are), and said they would think about it. As I reported before, *my* impression is that so many things in the AppleTalk stack need changing to work well in a large internet environment that they'll probably only come via a Major New Version. Are you ready for AppleTalk II? Or maybe OSITalk? - RL "Bob"
jmg@cernvax.UUCP (jmg) (05/18/88)
We have all of the problems mentioned in various articles with this subject: many Ethernet segments linked by bridges, hundreds of TCP/IP hosts, hundreds of PCs and vaxes, over 1000 Macs screaming for communications. We too are fed up with use of broadcast, frequency of broadcast, lack of security etc etc., and I have written to Apple to say much this. If I am not mistaken, there are plenty of people inside Apple who read this newsgroup. How come none of them have commented, if only to say that they are aware of the problems? A guy came here from Cupertino to talk about communications futures from Apple, and he claimed not to know about any dissatisfaction with EtherTalk!!! Come on, Apple, get your act together and tell us which way you are heading and when you might get there. ps. maybe Kinetics read this too: they would need to be compatible with any more intelligent LocalTalk bridging, management protocols and so on. -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (05/21/88)
In article <685@cernvax.UUCP> jmg@cernvax.UUCP () writes: > >If I am not mistaken, there are plenty of people inside Apple who >read this newsgroup. How come none of them have commented, if only to >say that they are aware of the problems? A guy came here from Cupertino >to talk about communications futures from Apple, and he claimed not to >know about any dissatisfaction with EtherTalk!!! > >Come on, Apple, get your act together and tell us which way you are >heading and when you might get there. > It could be that Apple isn't quite ready to talk about where they are going with large networking. I don't think it's with an extended AppleTalk. Why reinvent the wheel? Apple has TCP/IP for EtherTalk and LocalTalk in development under contract. (Please note that I have no special inside contacts for this, just inferences from elsewhere.) Apple will soon have the option for supporting TCP/IP, with the usual telnet/ftp/smtp utilities within the native MacOS on both LocalTalk and EtherTalk. If Apple doesn't go for IP, then the developer will bring it out. You almost certainly will have the option of going native IP if you want. But will it be enough for you? What about all those nifty self-configuring features of the current Apple protocols? They just might be the cost of going to large networks, I don't know. Certainly, TCP/IP doesn't solve the e-mail PC/server problem. Maybe Apple will figure out a way to extend the TCP/IP suite in a clean way or layer the Apple protocols on top of IP. Do you want to link Macs with IBM-PCs, but you don't want TOPS? You might see NETBIOS SMB filer server capability on Macs. This makes sense if you want to integrate into PC server/LANs. I don't think it's the way to go for TCP/IP networks with NFS, et al but I bet Apple is eyeing the corporate network environment. I think Apple is grappling with the "large Mac network" problem, but they probably aren't thinking "Mac IP network" but "how do we get into the corporate PC environment" network. Maybe that will be an IP network with Netbios on top, as well as AFP/etc from the current Apple protocol family. I wouldn't talk yet either, if I was Apple. Kent England, Boston University
jmg@cernvax.UUCP (jmg) (05/24/88)
In article <22769@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > It could be that Apple isn't quite ready to talk about where >they are going with large networking. I don't think it's with an >extended AppleTalk. Why reinvent the wheel? But AppleTalk exists (in quite large numbers I believe!) and will have to be integrated into large networking. The parallel is with Ethernet, where DEC have had their networking concepts reasonably well established for a long time: level 1 routers, area routers, bridges, routers and (their own brand, unfortunately) management. Thus I do not see that one can avoid extended AppleTalk, and Apple have implicitly acknowledged this with EtherTalk: they should have realised immediately where this would give problems. > Apple has TCP/IP for EtherTalk and LocalTalk in development >under contract. (Please note that I have no special inside contacts >for this, just inferences from elsewhere.) Apple will soon have the >option for supporting TCP/IP, with the usual telnet/ftp/smtp utilities >within the native MacOS on both LocalTalk and EtherTalk. If Apple >doesn't go for IP, then the developer will bring it out. You almost >certainly will have the option of going native IP if you want. But >will it be enough for you? My inferences are the same, and I will welcome native TCP/IP, including some kind of interface (sockets?) allowing us to write programs, rather than just running applications stand-alone. Until that happy day I will manage quite well with NCSA telnet and Brown's tn3270. Beyond that we can look forward to NFS. In fact, the TCP/IP situation is not my main worry, but rather the EtherTalk and zone bridging/management. > What about all those nifty self-configuring features of the >current Apple protocols? They just might be the cost of going to >large networks, I don't know. Certainly, TCP/IP doesn't solve the >e-mail PC/server problem. Maybe Apple will figure out a way to extend >the TCP/IP suite in a clean way or layer the Apple protocols on top of >IP. As I understand it, the self-configuring applies to AppleTalk node numbers, not to TCP/IP. Note that we have decided not to use the dynamic IP addresses: when I have problems with someone on an IP address I want to know who it is. I hope Apple will figure out how to layer Apple protocols onto IP. In fact, I hope that they will figure out a lot of things: the minimal thought that went into mapping the protocols directly onto Ethernet has, in my view, backfired on them. > Do you want to link Macs with IBM-PCs, but you don't want >TOPS? You might see NETBIOS SMB filer server capability on Macs. >This makes sense if you want to integrate into PC server/LANs. I >don't think it's the way to go for TCP/IP networks with NFS, et al but >I bet Apple is eyeing the corporate network environment. I would love to link Macs and IBM PCs. I don't want TOPS because I don't want to have to buy LocalTalk cards for all of the IBM PCs, and nobody ever replied when I asked if TOPS could go onto a PC with an Ethernet card (which one?). NETBIOS is a possibility, but I would want it to be on top of TCP/IP according to RFC 1001 and 1002: in the end I would want it to be able to access something like a Novell file server (yes, I know that the 3Com 3-server has AppleTalk included). > I think Apple is grappling with the "large Mac network" >problem, but they probably aren't thinking "Mac IP network" but "how >do we get into the corporate PC environment" network. Maybe that will >be an IP network with Netbios on top, as well as AFP/etc from the >current Apple protocol family. > > I wouldn't talk yet either, if I was Apple. Even big blue puts out statements of "strategic direction". We need to know what direction Apple is heading in, and the role of the current AppleTalk in the future. Remember, we here, as well as many other big sites, need communications now, not when Apple has put the last icons into their new comms strategy. -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
pz@Apple.COM (Peter Zukoski) (05/25/88)
In article <685@cernvax.UUCP> jmg@cernvax.UUCP () writes: >If I am not mistaken, there are plenty of people inside Apple who >read this newsgroup. How come none of them have commented, if only to >say that they are aware of the problems? A guy came here from Cupertino >to talk about communications futures from Apple, and he claimed not to >know about any dissatisfaction with EtherTalk!!! Well, yes, some of us at Apple do read this newsgroup. Some of us at Apple have even done something to have caused this newsgroup to exist. Some of us at Apple are no longer in any position to do anything about it. Many of the issues brought up are very frustrating for me personally also. I've been among the first to have to deal with very large networks. AppleTalk/VMS and MacWorkStation were two projects I was associated with which tried to address these issues. We may have created more problems than we originally had, but I feel that they're by and large a help rather than a hindrance. There's lots of issues inherent here that are just a real bitch to deal with. So, yes, we (some of us) know. We've got the same problems to handle here (ever tried planning a world-wide Appletalk network?), and we learn just the way everyone else does: try it and find out where it doesn't work. Then kludge a solution. The difference is, we then need to fix it right for everyone else. Not working in that group is (was - I'm not doing that stuff now) frustrating to me, because I can't make it happen faster. It's probably worse, because I don't see the situation as being hopeless, whereas you _out there_ having no information can just say "Well, that's the situation, now what can I do to make it work", and you just make it work. I get caught up in hoping that what's being done will solve my problems for me. Enough metaphysics. Just look at it this way: We've got the same problems you do. Well, I've said more than I should These are opinions, and have absolutely nothing to do with the organization I work for. Any similarity is purely coincidence.
tmanos@aocgl.UUCP (Theodore W. Manos) (05/30/88)
In Article <10984@apple.Apple.Com> pz@Apple.COM (Peter Zukoski) writes: >Well, yes, some of us at Apple do read this newsgroup. Some of us at >Apple have even done something to have caused this newsgroup to exist. >Some of us at Apple are no longer in any position to do anything about it. > ..... >Well, I've said more than I should >These are opinions, and have absolutely nothing to do with the >organization I work for. Any similarity is purely coincidence. Well, I, for one, give Peter a lot of credit for saying as much as he did, even if it wasn't much. It appeared to me that he was really straining at the bit to keep from saying more of how he *really* felt about the situation. I just can't help but wonder if the AppleTroopers have come and hauled this poor guy away already. Upper management at Apple should have as much guts (and common sense)! -Ted --------- Ted Manos tmanos@aocgl.{COM,UUCP,UU.NET} or ...!{uunet,mcdchg}!aocgl!tmanos