Cisco renamed the CE from "cache engine" to "content engine" because CEs provide much more than just basic web caching services. In this section, you will learn how to enable value-added services on your CEs, such as
Content Authentication and Authorization
With content request authentication and authorization, the CE can authenticate and authorize client requests before supplying access to cached or remote objects. With content request authentication, the CE ensures that your internal enterprise users requiring external Internet access are who they claim to be, by authenticating them with an external Authentication Authorization and Accounting (AAA) server. Once the CE authenticates those users, it can use authorization to ensure that the users have the privilege rights to access the requested objects.
For example, when a user requests an object, the CE sends their credentials to the AAA server. The AAA server verifies the user's credentials and responds to the CE with a pass or failure message. If the user's credentials pass authentication, the AAA server may also indicate the Windows-based groups that the user is a member of. The groups may be associated with the user's department or employment status (for example, regular or temporary). The CE can then make a determination, based on the group the user belongs to, of whether to supply the content to the requesting client. Figure 13-9 illustrates how content authentication and authorization with AAA works.
Figure 13-9. HTTP Authentication of Client Requests
For example, say that your organization does not offer web access to temporary contract employees, but only to regular full-time employees. Figure 13-9 could represent the following process:
To configure authorization rules for Windows-based groups, you can use ACLs containing permit or deny rules for particular groups. For example, you can use the ACL commands given in Example 13-5 to permit only employees who are members of the "fulltime" Windows group and deny all other employee access to the Internet. Example 13-5 configures an NTLM server at IP address 10.1.10.1 for authentication and group-based request authorization.
Example 13-5. AAA Request Authentication and Authorization
SSL Caching and Tunneling
You can also use CEs to cache SSL-encrypted objects, thus effectively offloading SSL computations and SSL object delivery from origin servers to the CE. To configure your CE to terminate SSL connections and cache SSL objects, you must install the origin server certificates and private keys on the CE whose secure sites you want to offload. You must use the SSL caching feature on SSL content that you manage yourself.
Alternatively, the CE can perform SSL tunneling for unmanaged objects. The Internet Draft "Tunneling TCP-based protocols through Web proxy servers" specifies the HTTP CONNECT method for a client to indicate to a CE that it should tunnel a TCP connection to the requested origin server. This draft is not protocol dependent; therefore, the CE does not need to be SSL-aware to coordinate the tunnel. The CE does not participate in the SSL handshake, and it does not supply a server certificate to requesting clients. The CE simply initiates a TCP connection to the server on behalf of the client. You can use either transparent redirection or proxy mode to perform SSL tunneling.
To create the SSL tunnel using the CONNECT method, the client opens a TCP connection over the SSL port and sends an HTTP CONNECT method (for example "CONNECT www.cisco.com HTTP/1.0"). If required, the CE can authenticate the client, using HTTP authentication and authorization that you learned about previously, before establishing the tunnel. The CE then establishes a TCP connection between itself and the origin server, and sends an "HTTP/1.0 200 Connection Established" to the client.
The benefit of SSL tunneling using the CONNECT method is that you can apply authentication and authorization to your client's SSL requests. You cannot perform filtering of the content because you do not install the server's certificate and private key on the CE with SSL tunnelingthe traffic remains encrypted between the client and the server.
The CE can also tunnel SSL traffic from clients that do not explicitly use the CONNECT method. The CE simply intercepts TCP connections to the SSL port and establishes another TCP connection to the SSL origin server. As with the CONNECT method, the client and server complete the TCP handshake without intervention from the CE. However, with this transparent SSL tunneling method, you cannot configure the CE to perform HTTP authentication and authorization with the client.
Internet Content Adaptation Protocol
You can configure Internet Content Adaptation Protocol (ICAP) to transparently adapt content for your clients. You can use third-party ICAP server applications in conjunction with your CE to perform the following value-added services to clients at the edge of your network:
In an ICAP design, the CE performs the role of an ICAP client. The ICAP client encapsulates the client's HTTP requests or responses, or both, into an ICAP request and sends them to an ICAP server for processing. An ICAP server can be a dedicated server that performs any of the previous functions separate from the caching functions of the CE, or is integrated within the CE as a third-party plug-in. Refer to your third-party ICAP server documentation for more details.
ICAP is a TCP/IP-based protocol and uses the default TCP port 1344. As with RTSP, ICAP is based on the HTTP protocol and shares many semantics with HTTP. For example, the ICAP response methods are the same as the HTTP response methods. However, there are currently three request methods that ICAP uses:
As with other caching services, you can use WCCP, a content switch, or direct proxy configuration to direct user requests to the CE. Figure 13-10 illustrates the flow of ICAP requests and responses between an ICAP client (that is, a Cisco CE) and an ICAP server (for example, a virus scanner) for ICAP RESPMOD processing.
Figure 13-10. ICAP RESPMOD Processing
Consider the ICAP RESPMOD example that is shown in Figure 13-10 in which a virus scanner ICAP server is used:
You can configure your CE to filter URLs within HTTP, HTTPS, FTP, RTSP, or MMS requests. The CE can apply local rules to the URLs or forward the client's requests to a third-party Employee Internet Management (EIM) URL filtering application for authorization. Following are the URL filtering applications that the Cisco CE supports:
You can direct client request packets to the CE by either WCCP, by a content switch, or by way of manual proxy configuration on the browser or media player. When the CE receives a TCP SYN request from a client through WCCP, it completes the TCP three-way handshake with the client to inspect the HTTP URL before sending the request to the origin server. Depending on what method you configure, the CE can then either check its local lists or forward the request to a third-party filtering application. If you use an external third-party filtering application, the CE forwards the request to the application and awaits an authorization response. The external application then inspects the URL and performs a lookup into its URL database. If the filtering application contains the URL in its database, it sends an authorization failure response to the CE. The CE then spoofs the connection to the client and sends a page to the client indicating that the user does not have permission to access the URL. If the URL is not within its database, the URL server sends an authorization success message to the CE. The CE then originates the client's request to the origin server, per normal caching procedures.
Adjusting TCP/IP Parameter Values
Another valuable function of a CE is its ability to fine-tune the TCP protocol to accelerate flows from an end-to-end perspective. As you learned previously in this Chapter, CEs interact with clients and origin servers in either proxy or transparent mode. In either mode, the CE establishes two TCP connections between itself and both client and origin server (that is, one TCP connection to the origin server and one to the client). In transparent mode, for the client-side connection, you learned that the CE spoofs the origin server's IP address. For the server-side of the connection, you learned how the CE can either use its own IP address or spoof the client's IP address.
Because the CE is involved in both the client and server sides of the TCP connection, you can configure your CE to adjust the following TCP parameters that you learned about in Chapter 2, "Exploring the Network Layers," in order to streamline the TCP flow:
Additionally, the CE can enable the following TCP features that are not enabled by default for most applications: