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
------