Enabling Transparent Value-Added Services on Your CEs


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

  • SSL caching

  • Content adaptation using Internet Content Adaptation Protocol (ICAP)

  • URL filtering

  • TCP/IP parameter value adjustments

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:

  1. When a user requests an object, the CE intercepts the request, using either proxy-mode configuration or transparently through WCCP or a content switch.

  2. The CE then challenges the client for credentials using the same TCP connection, by spoofing the origin server IP address.

  3. The client responds to the challenge with the user's credentials.

  4. The CE then opens a separate TCP connection to the AAA server to send the user's credentials for verification. The AAA server may be running TACACS+, RADIUS, LDAP, or NTLM.

  5. The AAA server processes the request and determines whether the username/password combination is correct. The AAA server includes the configured group to which the user belongs in its response to the CE.

  6. The CE then matches the content to the rules that you configure for the particular group. If the rules indicate that the group is authorized to receive the requested content, and if the CE contains a fresh copy of the requested object, it serves the object directly to the client. Otherwise, the CE opens a connection to the origin server, with its own IP address as the source, to retrieve a fresh copy of the content.

  7. The origin server provides a fresh copy of the content to the CE.

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

 ntlm server host 10.1.10.1 ntlm server enable access-lists 300 permit groupname mydomain/fulltime access-lists 300 deny groupname any access-lists enable 

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:

  • Human language translation

  • Content transformation (for example, XML to HTML)

  • Advertisement insertion

  • Virus scanning

  • Spam filtering

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:

  • REQMOD Used for request modification requests

  • RESPMOD Used for response modification requests

  • OPTIONS Used by the client to learn about supported methods of the ICAP server

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:

  1. The client browser unknowingly sends an HTTP request for an infected file from a website.

           GET /virus.exe HTTP/1.1       Host: www.infectedsite.com 

  2. The CE determines that the requested file is not cached and sends the request to the origin server.

  3. The origin server sends the response to the CE.

           HTTP/1.1 200 OK       <data of executable containing the virus> 

  4. The CE encapsulates the headers of the HTTP response into an ICAP request and sends to the ICAP server.

           REQMOD icap://icap.cisco.com/ ICAP/1.0          HTTP/1.1 200 OK        <data of executable containing the virus> 

  5. The ICAP server processes the origin server's response, determines that the file contains a virus, and formulates an error message for the client's web browser.

             ICAP/1.0 200 OK         Connection: close         HTTP/1.1 403 Forbidden         Sorry, the requested file contains a virus. 

  6. The CE decapsulates the ICAP response from the ICAP server and sends the ICAP server-generated HTTP message to the client browser.

URL Filtering

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:

  • Local URL list files You can manually configure "good lists" and "bad lists" containing URLs that you want the CE to filter against incoming client requests.

  • SmartFilter You can directly enable this local third-party plug-in on your CE.

  • Websense and N2H2 These are external third-party URL filtering applications. As with SmartFilter, you can also enable a local plug-in for Websense filtering.

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:

  • Send windows size You can adjust the advertised client and server send window sizes using the following commands:

     tcp server-send-buffer KB tcp client-send-buffer KB 

  • Receive windows size You can adjust the advertised client and server receive window sizes using the following commands:

     tcp server-receive-buffer KB tcp client-receive-buffer KB 

  • Initial congestion window (CWND) value You can adjust the initial CWND value using the command

     tcp cwnd-base segments 

  • Initial slow start threshold You can adjust the initial slow-start threshold using the command

     tcp initial-ss-threshold segments 

  • Transmit timer You can adjust the transmit timer value using the command

     tcp increase-xmit-timer-value value 

  • Client and server Maximum Segment Size (MSS) You can adjust the MSS using the commands

     tcp server-mss maxsegsize tcp client-mss maxsegsize 

Additionally, the CE can enable the following TCP features that are not enabled by default for most applications:

  • IP Type of Service (ToS) field You can enable ToS processing on your CE using the command

     type-of-service enable 

  • Enable TCP-over-Satellite You can enable TCP-over-Satellite using the window scale option (WSopt) on your CE using the command

     tcp server-satellite tcp client-satellite 

  • Enable Explicit Congestion Notification (ECN) You can enable your CE to inspect and use the ECN field, if available, using the command

     ecn enable 



Content Networking Fundamentals
Content Networking Fundamentals
ISBN: 1587052407
EAN: 2147483647
Year: N/A
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net