The Concept of Asymmetric routing

Asymmetric routing in general is a normal, but unwanted situation in an IP network. Asymmetric routing is a situation where for one reason or another packets flowing in i.e. TCP connections flow through different routes to different directions. As a rough example: Host A and B located in different continents are communicating through a TCP connection. Segments sent from host A to host B reach the destination through Sprint link but segments sent from B to A reach the destination through MCI link.
Asymmetric routing in general is a normal, but unwanted situation in an IP network. Asymmetric routing is a situation where for one reason or another packets flowing in i.e. TCP connections flow through different routes to different directions. As a rough example: Host A and B located in different continents are communicating through a TCP connection. Segments sent from host A to host B reach the destination through Sprint link but segments sent from B to A reach the destination through MCI link.

Asymmetric routing as described above is not a problem for current TCP/IP implementations, since TCP connection does not care which route a certain IP packet takes as long as it reaches its destination in a reasonable time.

Asymmetric routing can occur in a smaller scale also. It could happen in a situation where an organization uses two different routes, like a VPN and a leased line, for instance, to their branch office. In Full Cluster technology context, we speak about asymmetric routing when we have a situation where segments on a single connection come in to the network through one node and go out through another node. Below is the another example of Asymmetric traffic.

Asymmetric routing is not a problem by itself, but will cause problems when Network Address Translation (NAT) or firewalls are used in the routed path. For example, in firewalls, state information is built when the packets flow from a higher security domain to a lower security domain. The firewall will be an exit point from one security domain to the other. If the return path passes through another firewall, the packet will not be allowed to traverse the firewall from the lower to higher security domain because the firewall in the return path will not have any state information. The state information exists in the first firewall.

Traffic between the user PC and either the finance server or the WWW server can flow in an asymmetric manner at several points along the network. Between the PC and the finance server, switches S1 and S3 are the main location it can occur. Between the PC and the WWW server, traffic could take an asymmetric route at S1 and S2 or at the Internet when returning through ISP A or ISP B.So far, this is network design 101. Most network designers don’t have any problem with asymmetric traffic because IP networks are asymmetric by nature. At each point in the transmission, an IP router makes a forwarding decision based on its view of the network.

Now asymmetric flows really start to cause problems! Again, consider the PC communicating with server HTTP://WWW. A perfectly reasonable packet flow might have the outgoing connection flow through S4, S1, FW1, Inet_RTR_1, ISP A, and then to server HTTP://WWW. Along the way, FW1 learns that the PC is trying to communicate with server WWW, and so it adds an entry in its state table to enable the return traffic to flow when it comes back from server HTTP://WWW. Unfortunately, the return path for the packet from server WWW to the user PC happens to be ISP B, Inet_RTR_2, FW2, S2, S4, user PC. The packet never reaches the PC, though, because FW2 doesn’t have any state information for the communication. As far as it is concerned, server WWW is initiating new communications to the user PC that are blocked based on the configured security policy.
This problem can be further complicated by intrusion detection systems (IDS) deployed within the campus or near the firewalls. If traffic flows by an IDS in an asymmetric manner, it won’t see all of the data. Consequently, it might alarm on traffic that is benign (false positive), or it might miss an attack altogether (false negative).
I wish there were an easy answer to this problem, but unfortunately there isn’t. This section is included as much to bring the problem to your attention as it is to offer possible solutions. You do have some options, however:

·         Make your routing symmetric.

·         Load balance per flow rather than per packet.

·         Use state-sharing security devices.

·         Consider L2 redundancy as a workaround.

·         Manipulate flows by using routing or NAT.

·         Use stateless security features.

Make Your Routing Symmetric

This might seem easy, but in real network designs it can be a significant challenge. Even still, you would be surprised to see how many large networks use symmetric routing at certain parts of their network to enable state-aware security devices to function or to solve other networking issues. This is particularly common at Internet edges, where it is not unheard of to see an entire connection to an ISP lying dormant while the primary connection handles all of the load. Another example of Asymmetric route below.

Load Balance Per Flow Rather Than Per Packet

Most L3 devices can be configured to do one of two things when equal-cost paths exist for a given network destination. In the first option, packets are simply balanced in round-robin format, with each successive packet going to the next available upstream router. This option causes the most heartache with internal security systems such as IDS. The second, more preferred, option is to load balance based on a given flow. This means traffic with a particular source and destination IP address and port (often called a four tuple) is always sent by a specific upstream router. This allows IDS systems and other state-aware devices to at least see half of the communication in a consistent manner. Unfortunately, this does nothing to the return traffic, which still might flow over a different link.

Use State-Sharing Security Devices

As the problem of asymmetric traffic manifests itself more and more in networks, network security vendors are starting to offer options allowing the state information within one security device to be shared with another.  FWs 1 and 2 could exchange their state table information to ensure that if the other device sees part of a given flow, it will know to permit the traffic. Often, the amount of information exchanged is significant and requires that dedicated links be configured between the firewalls to exchange the state information.

Consider L2 Redundancy as a Workaround

With the careful introduction of L2 redundancy as opposed to L3, technologies such as Virtual Router Redundancy Protocol (VRRP) or Hot Standby Router Protocol (HSRP) can allow traffic to flow through a single location while still providing redundancy. This option works best on high-speed connections where the use of only one path instead of two or more does not affect network performance.
The result is that normally asymmetric flows can be made symmetric for short distances in the network, such as while traffic passes through a firewall. If FWs 1 and 2 were connected on both sides to the same L2 network, they could use something like VRRP to appear as a single firewall to the upstream and downstream routers. This means that traffic can flow in an asymmetric manner out to the Internet and to the internal network but in a symmetric manner when passing through the firewall. This is generally impossible when the two devices are not in close geographic proximity to one another. For example, if FW 1 is in Brussels, Belgium, and FW 2 is in Hackensack, New Jersey, you are out of luck.

Manipulate Flows by Using Routing or NAT

Because this is a book on security, the ins and outs of BGP path preference have no place within the text. It is worth noting, however, that there are a number of things that can be done with routing protocols to affect the paths that packets take. To some degree, you can also influence which path outside networks take when they must communicate with you. Although not very elegant, some other workarounds involve using different NAT pools based on which security device a packet passes through. Return packets can then be forced to a specific security device based on the unique NAT pool they allocate from.

Use Stateless Security Features

Even though firewalls have been around for many years, a number of companies still use basic ACLs instead of stateful firewalls for, among other things, this asymmetric issue. Some security functionality is clearly lost. Basic ACLs don’t track state information, but if your traffic flows are fairly easy to categorize, you can still achieve some security without needing symmetric traffic flows. Remember that if you have properly implemented a true security system as defined in Chapter 1, the access control function of a firewall is only one part of the overall security story.
With IDS, the signatures that work improperly in asymmetric environments can be turned off to prevent false positives. Again, this will reduce the security such systems provide but will still allow a number of signatures to fire properly.