Configuring AppleTalk Filtering via Access Lists

The packet-filtering facilities for AppleTalk in the Cisco IOS software enable a network administrator to restrict access to certain AppleTalk resources ”including individual servers, printers, network segments, ranges of addresses, and entire zones ”based on a variety of criteria. Like access list configuration for TCP/IP, the packet-filtering process consists of defining the filtering criteria and then applying the criteria to specific AppleTalk interfaces.

Defining Access Lists

AppleTalk access lists are slightly more complicated than TCP/IP access lists, in part because of the logical zones that can span multiple interfaces and AppleTalk network numbers . Furthermore, AppleTalk makes extensive use of device names ”as registered in NBP ”for workstation and server access to network resources. As examined earlier, the network.node addresses associated with those network resources may change over time based on the dynamic negotiation of a device's node address.

As a result of these conditions, we advise against using the AppleTalk filtering capabilities that allow filtering based on network addresses. Attempting to restrict access to resources in a particular zone by restricting access to a particular network or cable-range can be extremely tricky when that zone spans multiple interfaces and multiple geographies. Furthermore, an access list based on a network or node address may no longer work if that resource's address dynamically changes at some point in the future. Misconfigurations can result in allowing access where none is desired or unintentionally blocking access to those who need it.

Instead of filtering based on AppleTalk network addresses, we recommend filtering based on AppleTalk service names ”as registered in NBP ”and on the basis of zone name requests and propagation. Because these concepts are tightly coupled with AppleTalk operation, it is logical to control access based on these criteria. We examine both NBP and zone name filtering in the remaining portion of this section.

All AppleTalk filtering criteria are implemented via the IOS global configuration command access ”list using the lists numbered in the range 600 “699. Unlike IP and Internetwork Packet Exchange (IPX) access lists, the order of the AppleTalk access list commands is not important. However, two important criteria should be observed in the design of AppleTalk access lists.

First, access list entries should not overlap one another. An example of an overlap is permitting a particular network with a permit network command and then denying the same network with a deny network command. If you do enter entries that overlap, the last one you enter overwrites and removes the previous one from the access list. In this case, the permit network statement is removed from the access list when you type the deny network statement.

Second, AppleTalk logical filtering criteria and AppleTalk network filtering are implemented with the same access list, and both are evaluated simultaneously . Therefore, each access list must always have a method for handling packets or routing updates that do not satisfy any of the access control statements in the access list. To explicitly specify how you want these packets or routing updates to be handled, you must use one of the following commands, depending on your circumstances:

• The access-list other-access global configuration command, when defining access conditions for networks and cable ranges

• The access-list additional-zones global configuration command, when defining access conditions for zones

• The access-list other-nbps global configuration command, when defining access conditions for named network resources using NBP packets

These commands can be placed anywhere in the access list. The Cisco IOS software automatically places an access-list deny other-access command at the end of the access list. It also places access-list deny additional-zones and access-list deny other-nbps commands at the end of the access list when zones and NBP access conditions are denied, respectively. If you do not explicitly specify how to handle packets or routing updates that do not satisfy any of the access control statements, the packets or routing updates are automatically denied and, in the case of data packets, discarded.

To implement filtering based on network resource names, as they are registered with NBP, use the nbp keyword parameter of the numbered AppleTalk access list. Additional keywords enable you to filter based on object types, object names, the zone in which an object resides, or the type of NBP function. In the following example, we define an NBP filter on the San Jose router to prevent access to all servers in San Jose except a designated public server within the engineering department. The defined access list allows access to a named resource (in this case, the server Engineering Public), an object type (an AppleTalk file server or AFPServer), and the zone within which the object resides (San Jose Zone). The deny other-nbps option prevents access to all other named resources:

 San-Jose#  configure  Configuring from terminal, memory, or network [terminal]?  Enter configuration commands, one per line.  End with CTRL+Z.  San-Jose(config)#  access-list 601 permit nbp 1 object Engineering Public  San-Jose(config)#  access-list 601 permit nbp 1 type AFPServer  San-Jose(config)#  access-list 601 permit nbp 1 zone San Jose Zone  San-Jose(config)#  access-list 601 deny other-nbps  San-Jose(config)#  ^Z  

Zone name filtering allows for filtering both zone name requests and zone name propagation. We examine how each is applied in the next section. Both types of zone name filtering lists are implemented with the zone keyword parameter to the numbered AppleTalk access list. In the following example, we define a zone name filter on the Singapore router that denies access to the Operations Zone while permitting access to all others via the additional-zones keyword:

 Singapore#  configure  Configuring from terminal, memory, or network [terminal]?  Enter configuration commands, one per line.  End with CTRL+Z.  Singapore(config)#  access-list 605 deny zone Operations  Singapore(config)#  access-list 605 permit additional-zones  Singapore(config)#  ^Z  

Applying Access Lists

After the filtering criteria of an AppleTalk access list is defined, you must apply it to one or more interfaces so that packets can be filtered. Some applications of the access list can be applied in either an inbound or outbound direction on the interface. For the inbound direction, packets are coming into the router from the interface. For the outbound direction, packets are leaving the router and traveling onto the interface.

When AppleTalk access lists are defined as NBP filters, they are applied via the IOS interface configuration subcommand appletalk access- group . This command takes as a parameter the keyword in or out , with the default being out if no keyword is supplied. The following example applies the previously defined AppleTalk access list 601 on the San Jose router to the WAN interfaces, thereby allowing access to only the engineering public server from other parts of the ZIP network:

 San-Jose#  configure  Configuring from terminal, memory, or network [terminal]?  Enter configuration commands, one per line.  End with CTRL+Z.  San-Jose(config)#  interface serial 0/0  San-Jose(config-if)#  appletalk access-group 601  San-Jose(config-if)#  interface serial 1/0  San-Jose(config-if)#  appletalk access-group 601  San-Jose(config-if)#  ^Z  

To understand how AppleTalk access lists defined for zone name filtering are applied to zone name requests and propagation, a quick explanation of zone name management is required.

Zone names are mapped to network numbers on routers by the Zone Information Protocol (ZIP). When a router receives a new network advertisement in its routing table, ZIP enters the network into the Zone Information Table (ZIT) and sends out ZIP request broadcasts requesting information on which zones are mapped to the new network address. In this way, ZIP can build a complete list of all the zones that correspond to the network addresses learned via RTMP or EIGRP.

Workstation users are the primary beneficiaries of ZIP information. When an Apple Macintosh user opens the Chooser, ZIP zone list request packets are broadcast onto the local network segment. Any AppleTalk router on the local network segment can reply with a list of the available zones.

Note

Do not confuse our discussion of the Zone Information Protocol (ZIP) with our sample network for the Zoom Integrated Products (ZIP) company.

With the role of ZIP in mind, we can examine the two applications of AppleTalk zone name filters. To filter the propagation of zone names from one router to another, the IOS interface configuration subcommand appletalk zip-reply-filter is used. This filter works by causing the router to reply to ZIP requests for network-to-zone-name mappings with only the zone names permitted in the access list. Consequently, the appletalk zip-reply-filter applies only to reply packets that are outbound from the interface on which it is configured. In the following example, we configure the Singapore router with the previously defined AppleTalk access list 605 on its Ethernet interface to prevent any unknown routers from learning about the Operations Zone:

 Singapore#  configure  Configuring from terminal, memory, or network [terminal]?  Enter configuration commands, one per line.  End with CTRL+Z.  Singapore(config)#  interface ethernet 0  Singapore(config-if)#  appletalk zip-reply-filter 605  Singapore(config-if)#  ^Z  

To prevent users from learning about certain zones, use the IOS interface configuration subcommand appletalk getzonelist-filter . The filter works by causing the router to reply to ZIP requests for zone lists with only the zone names permitted by the access list. As with the appletalk zip-reply-filter , the only reply packets that are filtered are the ones outbound from the interface on which the getzonelist-filter is configured. In the following example, we configure the Singapore router with the previously defined AppleTalk access list 605 on its Ethernet interface to prevent any end user workstations from learning about the Operations Zone when viewing resources in their Choosers:

 Singapore#  configure  Configuring from terminal, memory, or network [terminal]?  Enter configuration commands, one per line.  End with CTRL+Z.  Singapore(config)#  interface ethernet 0  Singapore(config-if)#  appletalk getzonelist-filter 605  Singapore(config-if)#  ^Z  

Tip

As stated previously, when multiple routers are on a network segment, any one of them may respond to ZIP GetZoneList requests. Given this fact, it is important that zone name filtering be applied to all routers on the same network segment identically. Failure to filter identically causes users to be supplied with different zone lists, depending on which device responds to the request. Also, inconsistent filtering can cause the zones to appear and then disappear on the user's workstation every few seconds. Given the potential for inconsistencies, you should normally apply zone name filters only when all routers are IOS-based, unless the non-IOS routers have similar filtering capabilities.

You can view the behavior of access lists and verify that they have been configured properly by using the IOS EXEC commands show access-lists and show appletalk access-lists . The former command shows all access lists defined on the router, while the latter shows only AppleTalk access lists defined on the router. Each command can take as a parameter an access list number and can display only the contents of that list. If no parameter is supplied, all lists are displayed. Following is the output of the show appletalk access-lists command on the Singapore router for the earlier access list example:

 Singapore#  show appletalk access-lists  AppleTalk access list 605:   deny zone Operations   permit additional-zones 

The IOS EXEC command show appletalk interface shows where AppleTalk access lists are applied on an interface and for what filtering application. The last two lines of the following output on the Singapore router indicate that AppleTalk access list 605 has been applied as both a zip-reply-filter and a getzonelist-filter :

 Singapore#  show appletalk interface ethernet 0  Ethernet0 is up, line protocol is up    AppleTalk cable range is 4001-4010    AppleTalk address is 4008.30, Valid    AppleTalk zone is "Manufacturing"    AppleTalk address gleaning is disabled    AppleTalk route cache is enabled    AppleTalk GetZoneList filter is 605    AppleTalk Zip Reply filter is 605