- Business Environments
- High-Level Policies
- Low-Level Policies
- The Policy Management Tool
High-Level Policies
Within each of the environments described in the previous sections, different types of business needs motivate the deployment of the different technologies. This section looks at some of the business needs that can arise in each of the different environments.
The Enterprise Environment
Within the enterprise environment, the most common needs are that of satisfying the business SLAs that exist between the different parts of the enterprise. For security purposes, an enterprise might need to ensure that access to its network is secure and is accessible only to the employees or other entities that are authorized to have access to specific enterprise resources.
Note - These business needs in this section are intended as illustrative examples for use in subsequent chapters of the book. These examples are not intended as an exhaustive enumeration of all the business needs that can arise in the enterprise environments.
Business SLAs
It is a common practice in many business organizations to have SLAs in place among their different divisions. An SLA is an explicit statement of the expectations and obligations that exist in business relationships between a service provider and its customer [SLAREF]. In the case of an enterprise, the SLA defines the details of the services that an IT department in an enterprise is expected to provide to the other departments that use the computing/networking infrastructure.
Many enterprises choose to outsource the operation and maintenance of their computing infrastructure to another company. This is often the case when the enterprise does not consider running and operating a computer network to be its core skill. The subcontracting company is usually responsible for satisfying an SLA that specifies the performance objectives that are expected from the other company.
An SLA typically contains the following:
Description of the type and nature of service to be provided
Expected performance level of the service
Process for reporting problems with the service
Time frame within which a response or resolution of a reported problem is expected
Process for monitoring and reporting the service level
Credits, charges, or other consequences for the service provider in not meeting its obligation
If applicable, any escape clauses describing the conditions under which the SLA might not be valid
Although a significant part of the SLA deals with business aspects, such as the process for reporting problems, service-level compliance, the terms of credits, or escape clauses, I will focus more on the technical aspects of SLAs, such as how you meet the performance objectives outlined in the SLA.
Note - As a matter of terminology, some organizations differentiate between an SLA and an SLO (Service-Level Objective). The SLA refers to the overall business agreement and consists of multiple SLOs that need to be satisfied. One of these SLOs is a performance objective that must be satisfied.
A service's expected performance level has two major aspects: reliability and responsiveness. Reliability includes availability requirements, such as when the service is available and what bounds on service outages may be expected. Responsiveness includes how soon the service would be performed in the normal course of operations. In the context of a computer network, reliability is usually measured in the network's uptime, and responsiveness is measured as bounds on round-trip delays between two customer sites. In order to meet its SLA, the operator of an enterprise network needs to ensure that applications running on the network are available and are performing at the desired level for the target.
The goal for an enterprise IT networking provider is to ensure that the applications supported by to it have a performance that is good enough to meet specific response-time criteria. The performance would be the end-to-end response time of the applications running in the enterprise network.
Chapter 4 describes how business SLAs can be supported effectively by technologies such as capacity planning, Integrated Services, and Differentiated Services.
Extranets
Although the security needs of many enterprises are quite diverse, we will look at a security scenario that often arises in an enterprise environment. This scenario relates to the provisioning and configuring of extranets among different enterprises.
In an era where all enterprises are connected to the Internet, there are many reasons to move many common business-to-business functions to an Internet-based infrastructure. For example, a company might require that its suppliers conduct business with it electronically. Consider a soft drink bottling company that needs to procure various types of containers from its suppliers. Examples of such containers include plastic bottles, metal cans, and glass bottles. A large bottling company typically procures the containers from a variety of suppliers. Other items supplied by a contractor include labels, bottlecaps, and distilled water. Different bottling plants that are located in different geographic locations might have requirements for different quantities of each type of container or other supplies.
When the bottling company wants to obtain the containers or other supplies, it typically sends a bid out to its list of approved suppliers, who send back quotes and terms for providing the supplies. The bids might be accepted by the company according to a variety of criteria. Although this negotiation is typically done via paper contracts in a traditional fashion, the cost savings that can be realized by migrating the process to an electronic one are significant.
One of the ways in which this system can be realized is by having a bidding server that runs an application that manages the bids received for any specific component, such as containers. The bidding server would be placed so that it is accessible to the suppliers contracted by the company over the Internet. However, for security purposes, the bidding server must be accessible to only a selected subset of suppliers through the Internet.
Such an extranet can be supported and established using the network-level mechanisms of Internet Key Exchange (IKE) as well as the transport-level mechanisms of SSL or TLS. The details of how to exploit these technologies to support the notion of extranets are described in Chapter 4.
The Network Connectivity Provider
Within the context of the network connectivity provider, we will look at the business needs of supporting business SLAs and the creation of a VPN service.
Business SLAs
In the networking services provider environment, customers may use the ISP network in one of the three manners:
To access the Internet
To interconnect two or more of its sites
To access proprietary, industry-specific networks
Most customers in the real world probably want to do a combination of these methods. One of the business objectives of any ISP is to support the communication needs of its customers at a reasonable performance level. These target performance levels are often specified as part of an SLA between the customer and the service provider.
When a customer uses the ISP to connect two or more of its sites, SLAs can be defined to ensure some performance level on the network communication between the pair of access routers that connect those two sites. When accessing the Internet, the customer is present at one of the access routers but can communicate with any of the IXPs in the network. The end objective of the customer communication on the Internet is quite likely to be outside the administrative domain of the ISP. Although the ISP cannot honestly offer any assurances about the performance level of the network outside its domain, it can provide some assurances about the performance of the communication within its own domain.
The SLAs provided to the customer are often specified in terms of the delays that can be provided among the different access points within the ISP network. For example, the ISP might provide connectivity among two private campuses of its customer. It might offer an assurance about the maximum latency a packet would experience in the network between the two campuses. An example of such an SLA is the one offered by UUNET to its customers with leased-line access [UUNETSLA].
Another common performance metric used within SLAs relates to the maximum amount of bandwidth than an ISP will accept from the customer for transport across the network. The ISP promises to transfer the specified amount of bandwidth across its network without a significant loss rate.
The terms specified in the SLA might be the same for all the customers, or they might be different for different customers. The former is the more prevalent case in most ISP environments. However, there are many cases where the SLAs would be defined differently for different customers. A customer trying to distribute real-time stock quotes over the network is likely to demand tighter bounds on network latency from its ISP than a customer dealing primarily with storing and forwarding electronic mail.
As in the case of the enterprise environment, the SLAs within the network may be supported by a variety of techniques, including traffic capacity planning, rate control devices, or the deployment of Differentiated Services.
Virtual Private Networks
The most attractive customers for an ISP are enterprises that need to interconnect their campuses. Quite often, these enterprises have their own private network—their intranet. A typical enterprise network (such as the one shown in Figure 3.2) consists of several campuses with their individual LANs and a WAN connecting the campuses. The WAN usually consists of serial links, such as T1 or T3 links, or where bandwidth demands are not that intense—56Kbps dialed or leased lines. Other techniques used for WAN connectivity are frame relay and ATM connectivity services, which gained popularity in the 1990s. You typically run routers where the IP protocol treats the underlying frame relay or ATM links as a lower-layer protocol. The cost of leasing the links with the right bandwidth is usually the most important factor in the cost of operating the private network.
){kind=link}
Because of the growing popularity of the Internet, most enterprise campuses (at least the large ones) are connected to the Internet. The Internet is an open IP network that connects a large part of the world. This results in any pair of enterprise campuses having two paths between themselves—one through the WAN that forms the corporate intranet, and the other one through the Internet. Of course, the intranet path is more secure than the open Internet and is also likely to have much better performance characteristics. As a result, most large corporations maintain their own private corporate networks.
To the ISPs that provide Internet-based connectivity to the enterprise corporations, the emerging scenario provides an attractive option to provide virtual private networks. An ISP can give an enterprise customer the option of eliminating its intranet and replacing it with a virtual network that has comparable performance and security. Such an offering is the virtual private network (VPN).
A VPN provides logical connectivity among the different sites of an enterprise while insulating them from each other. Basically, only the sites involved in the VPN should be allowed to communicate with each other. The only exception to this rule is that every campus needs access to the public Internet through some security device, such as a firewall.
The cheapest VPN is obtained if the campus sites simply connect to the Internet and use encrypted tunnels to carry their traffic across the Internet. However, given the wide variety of threats that exist on the open network, as well as the wide performance fluctuations, it is much more likely that the VPN service would be offered on a private network physically separate from the one that the ISP uses for Internet connectivity. A customer network would get access to both the Internet and the ISP-private network. Several customers would be multiplexed to the ISP-private network. This would reduce the overall cost to the ISP of maintaining its network. The ISP would also be able to offer VPN access to the customer at a reduced cost instead of the customer's having an intranet.
Such a scenario is shown in Figure 3.5. An ISP offers VPN services to two customer enterprises on an ISP-private network. The first customer (Customer A) has three sites connected to the network. The second customer (Customer B) has two sites connected to the network. The ISP connects to other peer ISPs at an exchange point, but it typically supports the private connections from the customers within its own network. The customer sites are connected to both the ISP-private network and through firewalls to the ISP-public network. The firewalls connecting the customers to the Internet typically belong to the customer. At the access routers connecting the customer to the ISP-private network, the ISP has the onus of making sure that the customers are protected from each other. For the sake of brevity, the figure shows access routers and firewalls only at the first campus of both customers. It's implied that a similar structure needs to be in place at each campus.
){kind=link}
Figure 3.5
A VPN Deployment Scenario
The high-level policies for deployment—in this case, for the ISP—would be to define the proper set of VPNs and to enable access among its customers in the environment shown in Figure 3.5. Such a solution may be obtained by using IKE and IPsec-based encrypted communication.
Application-Hosting Provider Environment
Within the ASP environment, we will look at the problem of supporting business SLAs and access control as examples of business needs.
Business SLAs
In an application-hosting environment, a service provider can provide its customers with assurances about the availability and reliability of its hosting service. Most service providers promise a 24x7 uptime. In other words, the sites and systems are always operational. From a performance perspective, the application-hosting service provider needs to ensure that the service is running properly and adequately. The service provider also needs to provide SLAs regarding the performance of the applications that will be hosted on the site.
The SLA between the service provider and the hosted customer can be defined in many ways. The simplest and most intuitive way to specify the performance would be to define a response time for a hosted application. The system's response time depends on a variety of factors, including the application design as well as the amount of load in the system. The goal of an application-hosting provider is to ensure that the application operates with specific response targets.
Note that the response target for an application is different from the end-to-end response time that a user of the application service might see. The application-hosting provider has no control over the network that is used to access the application. The network, if congested, can degrade the throughput and end-user response time significantly. However, the application-hosting provider can provide assurance on the part of the server reaction time, which is the time that elapses between the arrival of a request and the beginning of the servicing of the request by the server.
A more typical SLA in the service provider environment might provide the hosted customer with limits on the network bandwidth or server capacity that the customer can use. The limits on network bandwidth can be specified in terms of the absolute bandwidth required, offering a specific customer a slice of bandwidth that connects the application hosting provider site to the Internet. Such an SLA might specify that a customer will receive a performance equivalent to the performance it would have received if it has a dedicated leased line of equivalent bandwidth. Similar rates can also be specified on the connection rates that are supported by the server.
The two most important factors comprising service provider SLAs are the total amount of access bandwidth and the server capacity (the rate of connections that the site can support) allocated to a customer. The fulfillment of business SLAs by an ASP typically involves allocating adequate amounts of these two resources to different customers.
Access Control
From a security perspective, the most complex task of a service provider is to manage the many different types of firewalls that typically exist in a server farm environment. These various firewalls are required to protect the different parts of the server farm from each other. Here are the security functions that need to be implemented in a server farm:
Protect the customer's applications from hackers on the Internet
Protect the different customers from each other
Secure each customer's access into his or her network
Secure the administration and management applications within the server farm from the customers
These functions are usually implemented in different firewalls. The goal of these multiple firewalls is to ensure that each customer has the right access to its own part of the server farm. Therefore, the best representation of the security policies in the server farm is provided by specifying each customer and the section of the ASP network that it is allowed to access.