The ONL Tutorial

Tutorial >> Examples

TOC

Filtering With TCP Flags

This page gives two examples of filtering with GM (General Match) filters that use TCP flags:

• Example A (Connection Monitoring)

Example A demonstrates basic usage of TCP-flags filtering by showing how to count TCP connection attempts and successful TCP flows.

• Example B (Simple SYN Flood Traffic Generation)

Example B demonstrates one application of TCP-flag filtering in generating a flood of false TCP connections that might be used to study the robustness of a network algorithm to mitigate SYN attacks.

A new version of the SYN Attack Mitigation Demo will also demonstrate how TCP flag filtering can be used.

Example A (Connection Monitoring)

Introduction

You can monitor the control part (SYN, FIN, ACK) of a TCP flow. Consider the one-NSP configuration shown in Fig. 1 where TCP traffic is generated by an iperf client running on n1p2. The traffic goes through the 8 Mbps bottleneck link at port 7; then out to port 6 where it is forwarded through output port 3; and finally on to the iperf server running on n1p3. The ACK path is the reverse path taken by the data packets; i.e., out n1p3, into port 3, out port 6, into port 7, out port 2, and into n1p2.

Location TCP Flags ON Port 2 (ingress) SYN Port 2 (egress) FIN, ACK Port 2 (egress) None

There are three GM filters, all located at port 2. One of the filters is installed on the ingress side, and two are installed on the egress side. In all cases, the 5-tuple part of the GM filter will match any TCP packet: src address = 0.0.0.0/0, src port = *, protocol = tcp, dst address = 0.0.0.0/0, and dst port = *. But the ingress filter matches only TCP packets that have the SYN flag ON; i.e., the connection setup packet from the sender. One of the two egress filters matches only TCP packets that have the FIN and ACK bits ON; i.e., the connection termination packet from the receiver. And the second egress filter is used to count all packets that do not match the FIN-ACK filter.

In the above figure, the three red squares indicate the bandwidth monitoring points. The one at IPP 2 monitors the traffic going toward the receiver before the bottleneck link. The one at IPP 6 monitors the traffic going toward the receiver that leaves the bottleneck link. And the one at IPP 7 monitors the returning ACK traffic coming from the receiver.

Steps (In Brief)

Here are the major steps in this example:

1. Create a basic 1-NSP dumbbell configuration
2. Configure the route tables at ports 2, 3, 6 and 7
3. Install the GM filters at port 2
4. Set the link bandwidth at port 7
5. Create the bandwidth chart
6. Create the SYN and FIN-ACK packet count chart
7. Start the iperf TCP server
8. Start the iperf TCP client
9. View the GM filter statistics

Steps (In Detail)

1. Create a basic 1-NSP dumbbell configuration
• Select Topology => Add Cluster.
• Select Topology => Add Link.
• Drag the cursor with the left mouse button from port 7 to port 6.
• Select File => Commit.


2. Configure the route tables at ports 2, 3, 6 and 7

Port	Next Hop
2	7
3	6
6, 7	Default Forwarding

Traffic from the source at port 2 should go to port 7 where it loops back into port 6. From port 6, traffic goes to port 3 and out to n1p3. Return TCP traffic (ACK packets) takes the reverse path along port 6, then port 7, and then to port 2 to n1p2. We create a single entry in the route tables at ports 2 and 3 to direct traffic to ports 7 and 6 respectively. At ports 6 and 7, we create local default entries.




For port 2:

• RLI Window:
  Select port 2 => Configuration => Route Table.
• Port 2 Window:
  Select Edit => Add Route.
• Port 2 Window:
  Enter 192.168.1.0/24 in the prefix/mask field and 7 in the next hop field.


For port 3:
• Repeat the above port 2 procedure on port 3 so that packets will go to port 6.

For port 7: Use default routing.
• RLI Window:
  Select port 7 => Configuration => Route Table.
• Port 7 Window:
  Select Edit => Generate Local Default Routes.
For port 6: Repeat the port 7 steps at port 6 and commit.
• RLI Window:
  Select port 6 => Configuration => Route Table.
• Port 6 Window:
  Select Edit => Generate Local Default Routes.
• RLI Window:
  Select File => Commit.


3. Install GM filters using TCP flag fields at port 2

The ingress GM filter will be used to count SYN packets, and the egress GM filter will be used to count FIN-ACK packets. The matching packets on the ingress side will be placed in the normal VOQs for forwarding to port 7. The matching packets on the egress side will be placed in its datagram.

For port 2, ingress SYN filter:
• RLI Window: Select Port 2 => Configuration => Ingress Filters.
• Port 2 Ingress Filter: Select Edit => Add General Match Filter .
• Enter:
  • 50 into the priority field

    Leave the default values for the src and dest address fields (0.0.0.0/0), the src and dest port fields (*), and the protocol field (tcp).

• Select 1 in the SYN flag menu.


Install the FIN-ACK filter at egress port 2

Install one GM filter to count FIN-ACK packets and one to count all other packets. In both cases, the matching packets are placed into queue 300. A FIN-ACK packet will match both filters. But the filter with its FIN-ACK bits ON is given a higher priority (50) than the other more general filter so that it will be selected for a FIN-ACK packet.

• RLI Window:
  Select Port 2 => Configuration => Egress Filters.
• First Port 2 Egress Filter:
  Select Edit => Add General Match Filter .

• Enter:
• 300 in the qid field
• 50 in the priority field
• Select 1 in the FIN and ACK flag menus.

Install the general filter at egress port 2
• RLI Window:
  Select Port 2 => Configuration => Egress Filters.
• Second Port 2 Egress Filter:
  Select Edit => Add General Match Filter .
• Enter:
• 300 in the qid field
• 55 in the priority field
• Select File => Commit


4. Set the link bandwidth at port 7

• RLI Window:
  Select Port 7 => Configuration => Queue Table.
• Port 7 Queue Table:
  Enter 8 in the Link Bandwidth dialogue box.
• Select:
  File => Commit
• Save the configuration


5. Create the bandwidth chart

The Bandwidth chart shows three bandwidths:

1. The sender's traffic bandwidth going into the bottleneck (port 7 link);
2. The bandwidth that makes it to port 3; and
3. The returning ACK traffic when it reaches port 2.


• RLI Window:
  Select Monitoring => Add Monitoring Display.
• Graph Title Dialogue Box:
  Enter Bandwidth in the Name box.
• Bandwidth Chart:
  Select Parameter => Add Parameter and select Enter.
• RLI Window:
  Select Port 2 => Monitoring => Ingress => Bandwidth to OPP .

  The Add Parameter dialogue box will appear.

• Add Parameter Dialogue Box:
  Enter 7 in the to port dialogue box.
  Enter 1 in the Enter Polling Rate dialogue box.
• Repeat for VOQ bandwidth from port 6 to port 3
• Repeat for VOQ bandwidth from port 7 to port 2


• Note that the legend labels can be modified by selecting on the label and updating the labeling information in the dialogue box that will appear.


6. Create the SYN and FIN-ACK packet count chart

The packet counts associated with the SYN GM filter at ingress port 2 and the FIN-ACK GM filter at egress port 2 can be added to a chart. You should see one SYN packet coming from n1p2 at the beginning of the TCP flow and one FIN-ACK packet going to n1p2 at the end of the TCP flow.


• RLI Window:
  Select Monitoring => Add Monitoring Display.
• Graph Title Dialogue Box:
  Enter SYN, FIN-ACK Rate in the Name box.
• Rate Chart:
  Select Parameter => Add Parameter and select Enter.
• RLI Window:
  Select Port 2 => Configuration => Ingress Filter .

  The GM Filter window will appear.

• Port 2 Ingress GM Filter Window:
  Select stats => Add to Graph

  The Statistics dialogue box will appear.


• Statistics dialogue box:
  Enter 1 in the seconds box.

  The SYN, FIN-ACK Rate chart appears.



Change the IPP2Filter0BW label on the SYN, FIN-ACK Rate chart
• Select the IPP2Filter0BW label

  The IPP2Filter0BW dialogue box appears.

• Change the IPP2Filter0BW name to SYN Pkts
• Check the rate box to change from displaying the absolute value.
• Select Change

  The label changes to SYN Pkts.


Add the FIN-ACK Pkts curve to the SYN, FIN-ACK Rate chart

Repeat the above steps for adding the FIN-ACK packet count rate to the SYN, FIN-ACK Rate chart by using the status field in the FIN-ACK filter at egress port 2.


• SYN, FIN-ACK Rate Chart:
  Select Parameter => Add Parameter and select Enter.
• RLI Window:
  Select Port 2 => Configuration => Egress Filter .
• Port 2 Egress GM Filter Window:
  Select stats => Add to Graph
  Enter 1 in the seconds box.


7. Start the iperf TCP server

   Start an iperf TCP server at n1p2 to act as a receiver. This server will run until you kill it with ctrl-c. After starting the server, start the iperf TCP client to act as the traffic sender.

Enter:

onlusr> source ~onl/.topology
onlusr> ssh $n1p3
$n1p3>  iperf -s

8. Start the iperf TCP client

Enter:

onlusr> source ~onl/.topology
onlusr> ssh $n1p2
$n1p2> iperf -c n1p3 -t 5

9. View the GM filter statistics

• The bandwidth chart shows the data bandwidth quickly reaching the bottleneck bandwidth of 8 Mbps and the ACK traffic is a small fraction of the data bandwidth. The SYN, FIN-ACK Rate chart shows that the SYN and FIN-ACK packets bracket the data traffic; i.e., the SYN packet appears at the beginning of the TCP flow, and the FIN-ACK packet appears at the end of the flow.


• You can view the number of packets matching the GM filters by selecting stats => Once in each GM filter. There should be one SYN packet coming from n1p2, and one FIN-ACK packet going to n1p2. The second GM filter at egress port 2 shows the number of ACK packets going to n1p2 but excluding the FIN-ACK packet.

The same setup could be used to count the number of TCP flows occuring between from n1p2 and n1p3. Furthermore, if you moved the GM filters from port 2 to port 7 or port 6, you could easily monitor TCP flows from any host if their traffic goes through the link between ports 7 and 6.

Example B (Simple SYN Flood Traffic Generation)

This example shows how you convert a normal TCP flow into one that is a SYN flood attack. In a SYN flood attack, an attacker repeatedly sends a single SYN packet to a server but never responds to the servers SYN-ACK packet. The result is that the attack eventually consumes all slots in the server's half-open connection table and prevents other legitimate users from connecting to the server. In a real attack, the attacker would use a bogus source IP address. This example shows how a similar traffic pattern could be generated using a GM filter in combination with a normal traffic generator.

The idea is that the attacker generates legitimate TCP traffic, and the GM filters drop all packets except the initial SYN packet. For example, the attacker functionality could be a shell script that repeatedly called a program that does nothing but to attempt to connect to and disconnect from a server. The GM filter shown below will drop all TCP packets except the one with the SYN flag ON.

• The figure shows the number of packets that matched the GM filter (and therefore were dropped).


• The output of the tcpdump program shows that the only packets making it to the server's network interface (n1p3) are the SYN packets. The other traffic is the server sending multiple SYN-ACK packets in response to the client's original SYN packet waiting for the ACK packet from the client that would signal the establishment of a complete connection.


• Notice also that the server continues to send SYN-ACK packets back to the sender (green curve). Note that the time period between the SYN-ACK packets doubles with each attempt.

Although you can generate a SYN flood attack using toolkits designed for this purpose, the user must run as the root user. The example here shows how you can effectively do almost the same thing using an ordinary socket program in combination with a GM filter.

Tutorial >> Examples	TOC