NetCache accepts client connections and initiates connections with origin servers. In forward proxy mode it retrieves data from origin servers on the network and replicates the most popular content locally.
With IP spoofing enabled, NetCache uses the IP address of the client as its source IP address when initiating connections with the servers. Caching functionality is as normal. There are a number of instances where this is desirable; such as gaining more accurate client statistics or allowing IP authentication on web sites.
Replies from the origin server will now be sent directly to the client so, for IP spoofing to succeed, it is necessary to ensure that routing is symmetric, i.e., the returning traffic must pass through the same redirection device as the outgoing traffic does - it must be redirected to the cache servers instead of reaching the actual client.
When clients and Web servers communicate together
Consider the following diagram: [ (a) and (b) are interfaces ]
internal --- (a) *L4 SWITCHING* (b) --- external
|
NetCaches
Hashing of the source and/or destination IP address is the most common method of load balancing traffic among cache servers. Other methods include selection of the least busy cache server or hashing of the URL. Hashing of IP addresses is the most useful for spoofing because it allows us to know which cache server to redirect returning traffic to when multiple cache servers are involved.
Forward Proxy Deployment
The destination IP address will vary frequently between requests so it makes sense to use this for traffic distribution.
The redirection policies on the interfaces would be:
(a) if (DEST TCP PORT == 80) { hash(DEST IP ADDR); }
(b) if (SRC TCP PORT == 80) {hash(SRC IP ADDR); }
Reverse Proxy Deployment
There will be little variation in the destination IP addresses, as there are a limited number of web servers, so client source IP addresses should be used for traffic distribution.
The redirection policies on the interfaces would be:
(b) if (DEST TCP PORT == 80) { hash(SRC IP ADDR); }
(a) if (SRC TCP PORT == 80) { hash(DEST IP ADDR); }
Forward and Reverse Proxy Deployment
There are customers who have client requests coming into their network (to reach their web servers) as well as leaving their network. So, we'd need to be able to combine hashing masks with TCP source or destination ports:
The above reduces to:
(a) if ((TCP SRC PORT == 80) || (TCP DEST PORT == 80))
{ hash(DEST IP ADDR); }
(b) if ((TCP SRC PORT == 80) || (TCP DEST PORT == 80))
{ hash(SRC IP ADDR); }
Table 1 summarises the various policies (match on source or destination TCP port and hash on source or destination IP address) that are required for IP spoofing to work. They must be assigned to the appropriate interfaces on the switching devices.
Input Match Hash Type Interface SRC Port DEST Port SRC IP Addr DEST IP Addr Forward Proxy Internal - X - X Forward Proxy External X - X - Reverse Proxy Internal X - - X Reverse Proxy External - X X - Table 1: IP Spoofing Policies
The Foundry ServerIron is not currently capable of redirecting traffic based on the source TCP port. This means that IP spoofing is not possible with this device. They are considering adding it in the future.
The Alteon devices are capable of redirecting traffic based on the source TCP port.
If undertaking transparent caching on TCP port 80 then they are unable to apply a hash mask on the source IP address. This implies that only a single cache server can be used.
However, it should be possible to configure the devices so that they are also listening on ports other than 80 and in this case they may implement FireWall Load Balancing. In this case, hashing of both source and destination IP address will occur. Multiple cache servers should, therefore, be feasible.
WCCP has the ability to redirect based on source and destination TCP ports - and also can use the source and destination IP addresses to hash upon.
However, currently, NetCache does not create the appropriate service groups... It will be available in a [near] future release...