Understanding the Network Topology Tree

The last section in this chapter describes what perimeters and interfaces are, where they are created, how they can be used to remove ambiguities in policy definition, which ones can be used in security policies, as well as how they are interpreted in policies.

Identifying Key Components in Your Network Topology

Before Cisco Secure Policy Manager can actually generate and publish, or distribute, network policies to the Policy Enforcement Points that you want the system to help you administer, you must identify all the Policy Enforcement Points and other hosts and servers that enable policy enforcement. The following list identifies the different network objects that you must define, assuming that they are part of your network infrastructure.

Internet Service Provider (ISP) Connections. The connections that you establish between your internal networks and one or more ISP are required for Cisco Secure Policy Manager to derive correct settings about which default gateways should be used, as well as to derive routing rules for Policy Enforcement Points. These connections are specified on the Internet node, which identifies the "sea of information" that is the most downstream point in the Network Topology tree. You can represent more than one ISP by specifying additional interfaces, and each interface can have multiple connections (default gateway addresses or high-speed serial connections).
Policy Enforcement Points. These network objects are those gateway objects for which you want Cisco Secure Policy Manager to generate and publish device-specific command sets. They act as concentrators, controlling the flow of traffic from one network to another based on defined policies. The following Cisco devices can be managed as Policy Enforcement Points:
- PIX Firewalls. PIX Firewalls provide perimeter security using access filters, address hiding, and stateful inspection for certain network services, which offers additional security features like Java blocking and TCP_SYN attack protection. In addition, later versions of PIX Firewall software (5.0 and later) support IPSec to enable secure communications with other IPSec-compliant gateways and hosts.
- Cisco routers running IOS software (IOS Routers). Within Cisco Secure Policy Manager, the IOS Router provides one or more functions, including acting as an IPSec gateway and endpoint, providing firewall features, and routing network traffic. The functions supported depend directly on the software image that is installed on the actual IOS Router.

Note The level of support that Cisco Secure Policy Manager provides for Policy Enforcement Points depends on the product type and the version of software that is running on the Policy Enforcement Point. In other words, not all products are supported in the same way. For example, Cisco Secure Policy Manager actually specifies the interface names and types for the interfaces installed in PIX Firewalls. However, for IOS Routers, this support is provided by other management applications. Cisco Secure Policy Manager requires these settings to be specified only to ensure that it generates the correct commands, not because it generates and publishes the commands that name and specify the type of interfaces installed in an IOS Router.

Tips You do not have to define all the Policy Enforcement Points that exist on your network manually, which can be a tedious task. Instead, if you have installed Cisco Secure Policy Manager on your production network, you can use the Topology Wizard to discover the device settings for any particular Policy Enforcement Point.

Cisco Secure Policy Manager Servers. The hosts on which you have installed components of Cisco Secure Policy Manager enable policy enforcement by generating and publishing the device-specific command sets or by monitoring the syslog data streams that the Policy Enforcement Points generate. These hosts do not include the GUI client-only hosts---such hosts are not required to be defined in the Network Topology tree.

: The primary reason that Cisco Secure Policy Manager must know of these servers is to ensure that the appropriate Policy Enforcement Points permit the required Policy Distribution Point-to-Policy Enforcement Point traffic to pass, which is required to publish the device-specific command sets. In addition, the Cisco Secure Policy Manager system must know how to communicate with the various hosts that compose the system in distributed installation types. After you associate a Policy Enforcement Point to a Cisco Secure Policy Manager server in the Network Topology tree, Cisco Secure Policy Manager automatically generates and applies the correct security policies that guarantee correct flows of this traffic. These security policies and servers are also automatically populated and applied under the Cisco System Folder in the Security Policy Enforcement branch.

Certificate Authority Servers. These special Host nodes run certificate authentication/generation software, such as the Netscape Certificate Authority Server. These servers are used by organizations that want to maintain strict control of their own certificate authority functions. In other words, these servers are responsible for verifying the public keys owned by users within that organization, thereby preventing man-in-the-middle attacks based on public-private key pairs. Within the Cisco Secure Policy Manager system, these servers enable policy enforcement by assigning and authenticating certificates used by the Policy Enforcement Points and hosts that participate in IPSec tunnels. IPSec tunnels are used to encrypt IP-based traffic that runs across untrusted and/or public network segments, such as the Internet, as well as to provide the secure download of device-specific command sets between Cisco Secure Policy Manager servers and the Policy Enforcement Points that they control.

: The primary reason that you must specify these hosts in the Network Topology tree is to ensure that Cisco Secure Policy Manager can generate the commands that ensure the appropriate Policy Enforcement Points permit the required Policy Enforcement Point-to-certificate authority server traffic to pass. Once you associate a Policy Enforcement Point to a certificate authority server in the Network Topology tree, Cisco Secure Policy Manager generates the correct security policies that enable this traffic to flow correctly. These security policies and servers are also automatically populated and applied under the Cisco System Folder in the Security Policy Enforcement branch.

Syslog Servers. These special Host nodes enable policy enforcement by monitoring the syslog data streams generated by the Policy Enforcement Points. Because Cisco Secure Policy Manager generates the commands required to redirect syslog data streams to various servers for analysis, you must specify these hosts in the Network Topology tree. Once you associate a Policy Enforcement Point to a syslog server in the Network Topology tree, Cisco Secure Policy Manager automatically generates and applies the correct security policies that guarantee correct flows of this traffic. These security policies and servers are also automatically populated and applied under the Cisco System Folder in the Security Policy Enforcement branch.

How the Network Topology Tree Organizes Device-Centric Settings and Rules

While the primary goal of Cisco Secure Policy Manager is to avoid device-centric views of your network and the devices that compose it, some settings and rules require that you consider the role that a specific network object has in your network. Many of these settings are peculiar to the network object, such as the name of the interfaces installed in a Policy Enforcement Point or the amount of disk space the Cisco Secure Policy Manager database can consume before it must archive or purge the oldest records. Most of Cisco Secure Policy Manager focuses on defining a high-level, abstract policy from which all appropriate, device-specific commands are generated automatically for you. However, the Network Topology tree enables few of these abstractions because it defines the physical layer of your network.

This section focuses on explaining the device-centric settings that you can define within the Network Topology tree. It also pays special attention to those settings that you must define. The purpose of this section is to help you understand why you must define these settings and to help you focus your energies correctly, because by knowing what you can specify within the Network Topology tree, you also know what you cannot specify, which encourages you to look outside of this tree to accomplish other goals.

Device-specific settings pertain to the proper operation of a network object in your network. Some network objects have relatively few device-specific settings, while others have a large number of settings. We can define six categories of device-specific settings:

Network interface settings. (required) A network interface is created by combining hardware and software in a way that frames can be passed across a transport medium. Because we assume that you are controlling TCP/IP-based traffic, this category organizes IP addresses, netmask values, hardware type, and slot configurations that are required for the device to send and receive TCP/IP-based packets. All objects within the Network Topology tree require some network interface settings, even if it is just a single IP address on a Host node.
Traffic flow settings. (optional) These settings shape the flow of traffic for all packets that meet the specific criteria, and for the most part, these settings are not service specific. Settings in this category include the MANUAL routing rules that cannot be derived for Policy Enforcement Points from the physical topology definition (refer to the "Learn More About the Routes Panel" section to understand the cases where you need to define manual routes), and any address hiding, static translation, or path restriction rules to be applied to network traffic traversing a Policy Enforcement Point.
Global service settings. (optional) These settings control all sessions of a specific network service type that traverse a Policy Enforcement Point. Settings in this category include global timeout settings, policy overrides, such as permitting return ICMP packets through a Policy Enforcement Point, and additional security mechanisms provided by a specific Policy Enforcement Point type, like Flood Guard for the PIX Firewall.
Policy enablement settings. (required) These settings are specific to enabling the use of Cisco Secure Policy Manager on your network. Settings in this category include administrative passwords required to access a Policy Enforcement Point, what network service to use to communicate with a Policy Enforcement Point, identifying special services running on a particular host (like certification authorities and syslog), IKE pre-shared secret/peer and trusted certificate authority declarations, identifying which Cisco Secure Policy Manager host will publish command sets to a specific Policy Enforcement Point, what IPSec tunnel templates to use to securely download the command sets, and specifying audit settings, like syslog configuration, monitoring points, audit event retention and archival settings.
Maintenance settings. (required) These settings are specific to the operation and maintenance of the device or host. Settings in this category include database size and archival settings for Cisco Secure Policy Manager hosts, the software image version installed on a Policy Enforcement Point, and what feature sets should be controlled by Cisco Secure Policy Manager based on the installed software image.
Policy override, approval, and publishing settings. (optional) These settings appear only in the Command panel of a Policy Enforcement Point node, but they provide important controls. Settings in this category include overrides via a prologue or epilogue command set, approval settings for manually or automatically publishing generated command sets to that Policy Enforcement Point upon a Save and Update operation, and whether or not current sessions of the Policy Enforcement Point should be reset, forcing all new sessions to comply with the downloaded command set. This category also includes the only feedback about the status of command publishing, including error and success messages.

Defining the Physical Network Topology

The Network Topology tree is more than just a place where you can identify your key network components and specify their device-centric settings. One of its most important functions is to clearly define the relationships among these key components and other network objects. These relationships enable Cisco Secure Policy Manager to derive critical information about the operation of your network, such as the default gateways for Policy Enforcement Points and the routing rules that ensure the proper flow of traffic across your network infrastructure. In fact, when you define device-centric settings, such as address hiding and path restriction rules, you are decorating these relationships with additional or modified properties.

Two components are critical to policy-based management, which provides an effective abstraction of a network and the services that run on top of the physical hardware of that network:

A logical description of the desired behaviors for services running across a network
A logical description of the objects that you want to control (for example, users, departments, or geographic sites)

However, for these two components to have any meaning and for the combination of the two (an abstract representation of applied policy) to be interpreted correctly, you must have some literal description of the services and a literal description of the network layout and contents . The Protocol Definitions, Network Services, Network Service Bundles, and IPSec Tunnel Templates branches found in the Tools and Services tree provide for a literal description of services (and policy abstracts and tunnel groups provide a logical description of the desired behaviors for those services).

The Network Topology tree provides the literal description of the network layout and contents (while the Security Policy Enforcement and Network Object Groups branches provide the logical description). The Network Topology tree describes what networks and hosts reside upstream of which Policy Enforcement Points so that when a logical policy statement of "Allow all Accounting Staff to access the Internet using a web browser" is interpreted, the hosts that compose the Accounting Staff can be translated into terms understood by the Policy Enforcement Points (IP addresses) and the Internet can be interpreted as the default gateway of the outermost Policy Enforcement Points that protect the various hosts that compose the Accounting Staff. In this way, the Network Topology tree acts as a Rosetta stone (that is, it gives a clue to understanding) for Cisco Secure Policy Manager to interpret the logical definition of your network policy into the device-specific command sets understood by different Policy Enforcement Points. The Network Topology tree is required to interpret the two combined logical elements in our policy-based system, which are policy abstracts applied to logical network object groups in the Security Policy Enforcement branch.

The tough question is "How much of my physical network topology do I have to define?" The answer is simple . With the exception of a few required components, such as the Cisco Secure Policy Manager hosts and other policy-enabling objects described in the "Identifying Key Components in Your Network Topology" section, you only have to define as much of your physical layout as is required to represent all the logical groups that you would like to define and protect. This answer seems ambiguous; however, consider that you must define all the objects that are required before you can define a host or network, which are primary constructors used in logical groups (folders) in the Security Policy Enforcement branch. Once you know the dependencies required to define the objects that you want to protect, you see that all other objects, such as gateways, parent networks, and Policy Enforcement Points, must be defined.

Tips This definition is not completely unambiguous. Cisco Secure Policy Manager provides a few logical grouping structures, such as clouds and IP ranges that enable you to shortcut the detailed description of your physical network topology. For more information on the complete list of network objects that you can define (including these logical structures), refer to the "How the Network Topology Tree Provides the Building Blocks for Network Policy Tree" section.

How the Network Topology Tree Provides the Building Blocks for Network Policy Tree

With the exceptions of unnumbered networks and cloud networks, any network object that you define in the Network Topology tree can be referenced directly in the Security Policy Enforcement branch, as well as in an IF Source is or IF Destination is condition of a security policy abstract or as a member of a Network Object Groups definition. However, some of these network objects can lead to ambiguous interpretation of the desired network policy. For more information on these ambiguities, refer to the "Learn More About Perimeters and Interfaces" section.

IPSec Tunnel Group references to network objects follow a simple rule that does not lead to ambiguous interpretation: "you can only specify as endpoints those network objects that have the IPSec Support box selected under Feature Set in the General panel."

This section explains each network object that you can define in the Network Topology tree and explains its purpose and intended use. It also identifies any dependencies of a particular network object. Two types of dependencies can exist for a particular network object:

Creation dependency. Refers to when a network object of type X requires that a network object of type Y must be defined before you can define the network object of type X.
Policy enablement dependency. Refers to when a network object of a particular type requires that, as part of its own definition, you reference another network object to enable some aspect of policy-based management. This type of dependency is not a creation dependency, which means you can partially define the network object and return later to complete the definition after you add another host that provides a policy enablement service, such as a certificate authority server.

Table 1-1 defines the available network objects, some of their uses, their dependencies, and whether or not you can reference them in policy conditions and tunnel groups and peers.

Table 1-1: Available Network Objects, Uses, and Dependencies

Object Type: Host node

Purpose/Intended Use: A host, such as a UNIX, Windows, or Macintosh client, to which you want to apply a specific network policy. Such network policies generally specify exceptions to more general policies that are applied to higher-order network objects, such as networks and IP ranges, or to logical groups constructed using Security Policy Enforcement folders. See also Server node.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: No.

Object Type: Server node

Purpose/Intended Use: Special hosts that run client/server products that Cisco Secure Policy Manager needs to know about to help enable policy-based management. These servers include any certificate authority servers, syslog server, and TACACS+ or Radius authentication servers that reside on your network.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: These hosts often serve as policy enablement dependencies for other network objects, but they never have such dependencies themselves.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: No.

Object Type: Primary Servers and Secondary Servers

Purpose/Intended Use: Special hosts that act as primary servers and secondary servers running the Cisco Secure Policy Manager components, including the Policy Distribution Point, Policy Database, Policy Monitor Point, and Policy Reporting Point.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: While these hosts always serve as policy enablement dependencies for other network objects, they can have any of the following dependencies:

Server nodes (certificate authority)

Server nodes (syslog servers)

Other network objects that act as IPSec tunnel peers to the primary or secondary server

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: Yes.

Object Type: IP Range node

Purpose/Intended Use: An IP range is useful for identifying a collection of hosts to which you want to apply a special network policy. Typically, IP ranges are used to apply policies to a specific range of host addresses on a particular network.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: No.

Object Type: Network node

Purpose/Intended Use: A network identifies those networks in which you are interested. These networks can be your network or networks, other than your own, in which you have a special interest (for example, you may have a special requirement for controlling access to those networks or you may want to establish an IPSec tunnel between one of their internal gateways and one of your Policy Enforcement Points).

Creation Dependencies: Internet node---or---Parent gateway (IOS Router, Router, Cloud, IOS Firewall, or PIX Firewall).

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: No.

Object Type: Internet node

Purpose/Intended Use: The Internet identifies all unknown networks. It is also the point of connection to your ISPs and acts as the default gateway from your trusted networks into your ISPs' access routers.

Creation Dependencies: None; always exists.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: No.

Object Type: Cloud node

Purpose/Intended Use: A cloud identifies a collection of networks for which you do not want to define the complete physical topology. Much like when you draw a network diagram on a piece of paper, you can use a cloud to depict those networks in which you have no direct interest, but which you need to represent to complete the diagram. For example, you might want to define an address hiding rule for a single network object that consists of a mesh of routers connected to networks for which you do not need to define the full topology. In other words, the only reason you would define them is to create the address hiding rule.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: Yes.

Object Type: Cloud Network node

Purpose/Intended Use: A cloud network identifies a network that resides within a cloud. These networks are not fully defined in that they are not connected to a true gateway like a router or PIX Firewall. Instead, the cloud under which they are defined acts as a special type of gateway for these networks. Cloud networks ensure that the correct routing rules are generated to permit traffic flows to/from those networks defined within a cloud, and they allow you to define network policy exceptions for network traffic destined to or originating from these networks. Cloud networks can only be defined within the Internet node or a Cloud node.

Creation Dependencies: Parent cloud.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes. In addition, it can indirectly inherit its parent cloud's properties.

Reference in IPSec Tunnel Groups and Tunnel Peers: Not directly. It inherits its parent cloud's properties.

Object Type: PIX Firewall node

Purpose/Intended Use: A PIX Firewall is a managed Policy Enforcement Point. As a gateway object, it is responsible for connecting two or more networks together and for routing and filtering the network traffic that traverses it (it enforces the high-level policies that you define). This Policy Enforcement Point type can also participate in IPSec tunnels, encrypting IP-based network traffic that flows between two such participants.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: (Required) Primary or secondary server acting as Policy Distribution Point. (Optional) Primary or secondary server acting as a Policy Monitor Point, server nodes (certificate authority or syslog), or other network objects that act as IPSec tunnel peers to the PIX Firewall node.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: Yes.

Object Type: Router node

Purpose/Intended Use: A Router identifies a generic gateway over which you do not have administrative control. As a gateway object, it is responsible for connecting two or more networks together. Router nodes can also participate in IPSec tunnels (assuming that they have been correctly configured); however, Cisco Secure Policy Manager does not generate or publish security policies to this gateway type. This node type is used by Cisco Secure Policy Manager to ensure that routes are generated correctly and, if it is a tunnel endpoint, that the correct IPSec command sets are generated for the Policy Enforcement Points you control that are peers in the tunnel group definitions.

The intended use of the Router node type is to provide a collection point for routing rules and shared IPSec tunnel secrets that are required on an uncontrolled gateway device to ensure that traffic flows according to the defined global security policy.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: None.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: Yes.

Object Type: IOS Router node

Purpose/Intended Use: An IOS Router is a managed Policy Enforcement Point. It can be a typical IOS Router, or it can act as a firewall when it has the Cisco Secure Integrated Software (CSIS) installed as part of its software image (see the Firewall Feature Set box in the General panel of an IOS Router).

As a gateway object, it is responsible for connecting two or more networks together and for routing the network traffic that traverses it. As a firewall, it is also responsible filtering the network traffic that traverses it (it enforces the high-level policies that you define). This Policy Enforcement Point type can also participate in IPSec tunnels, encrypting IP-based network traffic that flows between such participants.

While it is possible to disable the Managed Object property of this node type, we strongly recommend that you only use this node type when you are managing an IOS Router with Cisco Secure Policy Manager. If you want to treat an existing router generically, you should use the Router node type rather than the IOS Router node type. The primary reason for this recommendation is that using the IOS Router node generically creates artificial and indistinguishable perimeters, which could lead to the definition of invalid security policies.

Creation Dependencies: Parent network.

Policy Enablement Dependencies: (Required) Primary or secondary server acting as Policy Distribution Point. (Optional) Primary or secondary server acting as a Policy Monitor Point, server nodes (certificate authority and syslog), or other network objects that act as IPSec tunnel peers to the IOS Router node.

Reference in Security Policy Enforcement and IF Source/Destination is Conditions: Yes.

Reference in IPSec Tunnel Groups and Tunnel Peers: Yes.

Learn More About Perimeters and Interfaces

Two special object types are created as part of the definition of network objects that act as gateways. These two special object types are called perimeters and interfaces. While these objects are not actual network objects, they can be referenced in the IF Source is and IF Destination is conditions, which help eliminate/prevent the ambiguous interpretation of the desired network policy.

The ambiguities arise when trying to interpret network objects that act as gateways. Because the gateway objects are multi-homed hosts (meaning they have addresses on more than one network), it is not always possible to understand exactly which IP address assigned to which interface of the gateway object should be interpreted as the source or destination of the communication flow that you want to control.

In some cases, all the addresses may be the desired interpretation, and in such a case, you can apply a security policy directly to that node, and using the IF Source is or IF Destination is condition, you can specify how you want that node and all its addresses to be interpreted. However, the "all addresses" interpretation is not always desired, and the perimeter and interface objects provide two more precise forms of interpretation.

A perimeter represents a collection of interfaces, which have networks and IP addresses assigned to them. Further, a perimeter represents a closed, defensible boundary. In other words, data cannot flow around a perimeter---it must traverse from one perimeter to another. Perimeters are significant because traffic can only be controlled (policies can only be enforced) when a network packet passes between two perimeters. With the exception of the Internet Perimeter (which is pre-defined), you can only define a perimeter when you add a Policy Enforcement Point to the Network Topology tree, and all such perimeters are bounded fully by Policy Enforcement Points. The Internet node has a perimeter named the Internet Perimeter, which represents the collection of all unknown networks and all those networks defined between your outermost Policy Enforcement Points and the Internet node.

For a Policy Enforcement Point, you can define exactly one interface per perimeter because a Policy Enforcement Point can control the flow of traffic between its own interfaces; it can deny a packet from passing between two of its interfaces. When you define a security policy, you can specify a perimeter as either the source or destination of the traffic stream that you want to control. In this way, you can restrict traffic flows between collections of interfaces.

Note Non-Policy Enforcement Point gateways, such as Routers and Clouds, inherit the perimeter of the downstream Policy Enforcement Point (or Internet node, if a downstream Policy Enforcement Point is not defined) to which they are attached. You cannot define a new perimeter on these gateway objects because they are not managed devices and, therefore, they cannot be used to control the flow of network traffic.

In addition, you can only assign more than one interface to the single perimeter that resides on unmanaged gateway objects, such as Routers and Clouds, and to the Internet Perimeter, which represents a logical perimeter.

The network interface represents a connection to the network, such as an adapter or port, that accesses a physical wire. The IP addresses that are assigned to an interface represent the actual addresses that are assigned to the adapter or port that the interface represents. Hosts that want to deliver packets through a Policy Enforcement Point must be aware of these IP addresses, and often, the addresses serve as the default gateway used by hosts that reside on the same networks as the interface addresses. The networks organized under the interface represent the networks that are directly connected to the adapters or ports, which means that the IP addresses assigned to an interface must be members of the networks that are organized below the interfaces.

An interface is a collection of networks and IP addresses. As with perimeters, you can only control the traffic that originates from or is destined to an interface residing on a Policy Enforcement Point. On a PIX Firewall, you can only define one network and IP address pair per interface. However, for an IOS Router or an IOS Router running the CSIS image, you can define multiple networks and multiple IP addresses for each network per interface. When you define a security policy, you can specify an interface as either the source or destination of the traffic stream that you want to control. In this way, you can restrict traffic flows between collections of networks.

Within Cisco Secure Policy Manager, we refer to two types of interfaces: real and virtual. Real interfaces represent the physical connection to the network media. Virtual interfaces represent logical adapters that do not have a physical point of connection to the network. We also refer to the orientation of interfaces. Each gateway object has exactly one downstream interface, which is the interface connected to the network closest to the Internet node in the Network Topology tree. For a PIX Firewall, this downstream interface is the outside interface (except for the case of an inverted/flipped PIX Firewall). A gateway can have multiple upstream interfaces, which are those interfaces connected to the more internal networks in the Network Topology tree. All Policy Enforcement Points have at least one upstream interface. For a PIX Firewall, the inside interface and any DMZ interfaces installed in the Policy Enforcement Point are upstream interfaces.

You may have difficulty distinguishing between perimeters and interfaces, especially as you try to decide which to use when defining a source or destination condition. A quick scenario clarifies the difference. Consider a network topology that has two Policy Enforcement Points: Policy Enforcement Point X is attached to the Internet and Policy Enforcement Point Y is nested inside Policy Enforcement Point X. In this scenario, three perimeters exist:

Internet Perimeter, which is bounded by the outside interface on Policy Enforcement Point X
Perimeter XY, which is bounded by the inside interface on Policy Enforcement Point X and the outside interface on Policy Enforcement Point Y
Perimeter Y, which is bounded by the inside interface on Policy Enforcement Point Y

As this scenario shows, Perimeter XY contains two interfaces. A policy containing the condition If destination is Perimeter XY would evaluate against all addresses represented by the network objects defined between the two interfaces, as well as any addresses assigned to both of these interfaces. Whereas, a policy containing the condition If destination is inside interface on Policy Enforcement Point X evaluates against only the addresses assigned to that specific interface.

Figure 1-1 further illustrates these two concepts. In this example, one PIX Firewall is nested below another PIX Firewall. Because the PIX Firewall can be managed by Cisco Secure Policy Manager, a specific Policy Enforcement Point has exactly one interface attached to a perimeter.

Figure 1-1: Example Topology with Nested Perimeters

In Figure 1-1, P1 Interface 2 and P2 Interface 0 are both attached to Perimeter B. When a packet crosses a perimeter, however, it can be modified by a Policy Enforcement Point. In other words, the packet can be permitted, denied, or the data within the packet can be modified, such as by applying address translation or filtering Java.

In the above example, network packets can be modified when they flow between any of the perimeters: the Internet Perimeter, Perimeter A, Perimeter B, and Perimeter C. When you define a security policy abstract, keep in mind that you can only enforce that policy against packets that traverse between two perimeters, and only if you control one of the edge devices (a Policy Enforcement Point) on that perimeter.

Also, P1 Interface 0 and P2 Interface 0 represent downstream interfaces, whereas P1 Interface 1, P1 Interface 2, and P2 Interface 1 all represent upstream interfaces.

Table of Contents