Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!CHPC.BRC.UTEXAS.EDU!xxss520 From: xxss520@CHPC.BRC.UTEXAS.EDU ("L. Stuart Vance") Newsgroups: comp.protocols.appletalk Subject: AppleTalk in large diverse networks Message-ID:Date: 11 May 88 22:03:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "L. Stuart Vance" Organization: The Internet Lines: 82 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 ------