strick@SLCS.SLB.COM (03/02/91)
We have an existing world network supporting DECnet and IP. Many of
our sites have local AppleTalk networks as well. We are ready to
start connecting these AppleTalk LAN's to support a wide area network
of AppleTalk.
I'd like to hear from others who have done this.
1. What are the methods you use for Wide Area AppleTalk?
2. Do you have a scheme for AppleTalk net numbers?
3. What services are supported on the WAN?
Timbuktu, AppleShare, Printing, Public Folder, X-Windows?
4. How do you address security?
Don W Strickland Internet: strick@slcs.slb.com
Schlumberger Laboratory Compuserve: 70531,2666
for Computer Science Connect: strick
Austin, TX, USA AppleLink: N1090fortinp@bwdls56.bnr.ca (Pierre Fortin) (03/04/91)
In article <32816@boulder.Colorado.EDU>, strick@SLCS.SLB.COM writes: > > We have an existing world network supporting DECnet and IP. Many of > our sites have local AppleTalk networks as well. We are ready to > start connecting these AppleTalk LAN's to support a wide area network > of AppleTalk. > > I'd like to hear from others who have done this. > > 1. What are the methods you use for Wide Area AppleTalk? We use cisco's ATP1 implementation. > 2. Do you have a scheme for AppleTalk net numbers? Yes, ALL must be unique! So we centrally control these. We have also specified recommended naming conventions for the zones (remember the Chooser). > 3. What services are supported on the WAN? > Timbuktu, AppleShare, Printing, Public Folder, X-Windows? All, though I'm not absolutely certain about Timbuktu (Ben??) > 4. How do you address security? User education. We also provide the network applications preconfigured to turn off server functions (disallow incoming ftp on the telnets, etc.) 5. Would you do it again? (4. was the last of the original questions :^) NO WAY! With the advent of MacTCP, HyperFTP, etc., I'd tell the users to use TCP/IP protocols only. We are weaning (winning :^) some of our users over to HyperFTP using a UNIX box as a meeting point; just HyperFTP a file from a Mac to a UNIX machine in MacBinary format, then HyperFTP get it at another Mac and Voila! a double-clickable file. Another approach which we have in "user trial" mode is IPT's uShare: definitely not for the faint of heart... 6. Are the users really using the WAN? Not sure, but I'd sure as heck like to know. Oh, they're using AppleShare alright, but I'd be surprised if they are printing over the WAN (better to get the file and print locally...) 7. What ATalk routers do you have on your AT internet? ONLY cisco and KFP4s running K-Star. If you don't want to turn grey (not to mention hot shades of red :^), get rid of all other types. Our goal is to migrate all our Macs onto Ethernet and do away with as many KFPs as possible. Ben Schmidt (next office) is more tolerant of ATalk than I am; but it kills me to see the grief he's gone through to get ATalk to work just within BNR (about 3000 devices on three continents in 200+ nets/zones). Now, there are some in our parent company who want hook their Macs into our Apple internet. We have successfully resisted this to date. 8. How big an AT internet can you build? That's an easy one: it must *NEVER* have a diameter (in *any* direction) which will exceed AT's 15 hop limit. Remember: a Mac on LocalTalk to a KFP on Ethernet to a cisco, over a serial link, another cisco, ethernet to another KFP to another Mac results in a network diameter of **FIVE** nets... and the limit is 15...! 9. Will Ben ever write a book on this? He's certainly got enough material on the subject... :^) :^) And now a question for you, Don... It's a quarter to AppeTalk, do *you* know where all your ATalk routers are...? :^) :^) (quarter is a measurement of time...) Seriously, the first thing you want to do is have (in great gory detail): - a list of *ALL* ATalk routers on the LANs of interest - a list of *ALL* ATalk net numbers on these LANs - a list of *ALL* the zone names for these nets - a list of *ALL* the users who have dial-up devices on your LANs - a list of (well you should be getting the idea...) Next, map out how you want to handle the nets/zones i.e., will you define all of these, or define ranges, or naming/numbering conventions, let the users pick and choose... The cisco hardware should be at MCI-1.7, SCI-1.1 microcode levels. The firmware should be the *latest* available from cisco at the time you are ready to begin. > > Don W Strickland Internet: strick@slcs.slb.com > Schlumberger Laboratory Compuserve: 70531,2666 > for Computer Science Connect: strick > Austin, TX, USA AppleLink: N1090 ...and lastly, Good Luck, you'll need it... :^) Cheers, Pierre Cheers, Pierre Fortin fortinp@bnr.ca (613)763-2598
bschmidt@bnr.ca (Ben Schmidt (BNR)) (03/05/91)
In article <1991Mar3.235147.6931@bwdls61.bnr.ca> fortinp@bwdls56.bnr.ca (Pierre Fortin) writes: > Yes, ALL must be unique! So we centrally control these. We have also > specified recommended naming conventions for the zones (remember the Chooser). Essentially you want the entire zonename to be visible. With the current System Release 6.0.x Chooser that means approximately no more than 16 characters. With the Chooser in System Release 7.0, the full 32 characters allowed under ATalk's ZIP for zonenames, should be visible. > > > 3. What services are supported on the WAN? > > Timbuktu, AppleShare, Printing, Public Folder, X-Windows? > > All, though I'm not absolutely certain about Timbuktu (Ben??) Yup, Timbuktu works over our AppleTalk WAN. Performance varies on who you talk to. For file transfer, early versions of Timbuktu used some pretty non-optimum settings for ADSP. Newer versions seemed to have addressed this, although screen-sharing is still done over DDP which means that error-recovery, timeout, packet re-ordering is completely under program control. It's anyone's guess how well the program handles narrow WAN links compared to Mac-to-Mac over Ethernet. > > 4. How do you address security? > > User education. Lot's of. For example, don't leave things in Michael Pierce's Public Folder INIT. Don't leave your Timbuku wide-open to remote access. Ensure that Guest Access is truly limited on your private AppleShare fileservers. I anticpate personal AppleShare in System 7.0 will introduce new ways for people to inadvertently expose themselves on the network, but that's what makes life interesting. :-) >We also provide the network applications preconfigured to > turn off server functions (disallow incoming ftp on the telnets, etc.) This is a tough user education point, as so many people are unaware that a very useful FTP server is built into just about every Mac telnet going, and they should disable when they don't need it, or setup a password. (Setting up a password in NCSA telnet, for one, is decidely un-Mac like :-) And we monitor the number of ATalk nets and zones on our internet daily to detect failures or accidental (or otherwise) connection of our ATalk network to another, with the security exposure that that implies. > Oh, they're using AppleShare > alright, but I'd be surprised if they are printing over the WAN (better to > get the file and print locally...) Printer access is done via PAP and like AFP, it doesn't always responsd to narrow WAN links, dropped packets, etc. in an optimum manner. If only Apple would let you tune timeout's, and window sizes!! And of course LaserWriters have their own job-kill timeouts which can make printing a large report over a WAN, an exercise in futility. > 7. What ATalk routers do you have on your AT internet? > > ONLY cisco and KFP4s running K-Star. If you don't want to turn grey (not > to mention hot shades of red :^), get rid of all other types. Our goal is > to migrate all our Macs onto Ethernet and do away with as many KFPs as > possible. Well I'd like to temper that for my friends at Cayman, NRC, Webster, etc, by saying that each AppleTalk router has it's own idiosyncracies. When building a large internet with finite resources, it's better to have a few vendor types whose idiosyncracies you understand **well**, then having a vendor-of-the-month approach. So the message is less "which vendor(s) you use", and more "pick a small number of vendors and know their product well". Sort of like the 1990's morality on safe sex! :-) And as far as Ethernet is concerned - well if you've got 1000's of Ethernet drops for UNIX workstations anyhow, it can actually be cheaper from the point of view of maintenance of multiple technologies, to encourage direct Ethernet connection for your Macs, new laser printers, etc, rather than encouraging a proprietary physical layer topology like LocalTalk. But of course, each site is unique. > 8. How big an AT internet can you build? > > That's an easy one: it must *NEVER* have a diameter (in *any* direction) > which will exceed AT's 15 hop limit. Remember: a Mac on LocalTalk to a KFP > on Ethernet to a cisco, over a serial link, another cisco, ethernet to another > KFP to another Mac results in a network diameter of **FIVE** nets... and the > limit is 15...! You can engineer around this, although WAN's cannot be cheaply configured as star topologies, the way that MAN's can. I mean, it's a lot cheaper to daisy-chain links around the world, then star everything back to Paris, in order to minimize hop count! :-) But an even more frustrating problem in a mesh network, is that your primary links can be ignored by AppleTalk, in favour or your skinny backup links. The classic "1" 56kbit/sec link is better than "2" consecutive T1 links decision, made by all distance routing algorithms, including Apple's RTMP. Hence it can be downright difficult for an AppleTalk WAN to take advantage of automatic fault-tolerance without ensuring all links are the same speed. > Seriously, the first thing you want to do is have (in great gory detail): > - a list of *ALL* ATalk routers on the LANs of interest remember you're going to have to ensure that these are properly configured, maintained, upgraded (ATalk phase 2, etc), or face choas... > - a list of *ALL* ATalk net numbers on these LANs for uniqueness of ATalk net numbers... > - a list of *ALL* the zone names for these nets the Chooser sorts the list alphabetically, so a domain-style naming scheme will give you a geographical sorting of your zones...lower-case zone names make better use of minimal Chooser zonename specify than upper-case zonenames, since a proportional font is used. > - a list of *ALL* the users who have dial-up devices on your LANs It won't help for you to ensure that all AT net numbers are unique if someone is routinely dialing-in from the local University or competition down the road and inadvertently interconnecting your ATalk network with theirs with each phone call. The clash of AT net numbers will mess up the routing tables. The appearance of new AT net numbers from the foreign AT network can cause what's known as a ZIP storm as all your AT routers attempt to find out the zonenames associated with the dialed-in ATalk internet. :-) ...and lastly, Good Luck, you'll need it... :^) Come now, it's not that bad. There's nothing here that you didn't learn setting up a global DECnet and IP internet, right? best wishes, Ben Schmidt Bell-Northern Research, Ltd. Ph: (613) 763-3906 Information P.O. Box 3511, Station C FAX:(613) 763-3283 Technology Ottawa Canada K1Y 4H7 bschmidt@bnr.ca
kevinh@cmi.com (Kevin Hegg) (03/12/91)
>>We also provide the network applications preconfigured to >> turn off server functions (disallow incoming ftp on the telnets, etc.) > >This is a tough user education point, as so many people are unaware that >a very useful FTP server is built into just about every Mac telnet going, >and they should disable when they don't need it, or setup a password. >(Setting up a password in NCSA telnet, for one, is decidely >un-Mac like :-) I understand setting up passwords with NCSA Telnet, but doesn't this apply only to NCSA Telnet users? We are just now implementing a WAN with a number of outside access points, so security is becoming more of a concern than before. Anyway, there is a stack called HyperFTP which is readily available. I don't see any mechanism to prevent someone from using this to FTP to any Mac. Does anyone know of a way to prevent uncontrolled access to Macs with HyperFTP or any similar program? Is Apple doing anything to improve the security of Macs using MacTCP? It seems to me that the proper place for security is in the MacTCP software. Kevin Hegg, EDS Corp - Center for Machine Intelligence 2001 Commonwealth Blvd., Ann Arbor, Michigan 48105 Phone: (313) 995-0900 Internet: kevinh@cmi.com Applelink: D5990
bschmidt@bnr.ca (Ben Schmidt (BNR)) (03/14/91)
In article <9176@etsu.CMI.COM> kevinh@cmi.com (Kevin Hegg) writes: > I understand setting up passwords with NCSA Telnet, but doesn't this apply > only to NCSA Telnet users? We are just now implementing a WAN with a > number of outside access points, so security is becoming more of a concern > than before. Anyway, there is a stack called HyperFTP which is readily > available. I don't see any mechanism to prevent someone from using this to > FTP to any Mac. Does anyone know of a way to prevent uncontrolled access > to Macs with HyperFTP or any similar program? Is Apple doing anything to > improve the security of Macs using MacTCP? It seems to me that the proper > place for security is in the MacTCP software. HyperFTP implements an FTP client, not a server. It's use on any Mac does not compromise the security of that Mac. The only Macs whose file security is potentially at risk are those Macs running FTP servers. The most common FTP server implementation on a Mac is that built into most mac telnets. Hence secure the Mac telnets by disabiling FTP by default, or by adding a password, and you've secured all the Macs on your network from inadvertent FTP access. Ben Schmidt Bell-Northern Research, Ltd. Ph: (613) 763-3906 Information P.O. Box 3511, Station C FAX:(613) 763-3283 Technology Ottawa Canada K1Y 4H7 bschmidt@bnr.ca