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.
