Continuing our previous blog “Using sFlow with 6WIND’s High Performance vRouter” when we chronicled Arbor Networks’ use case example, we will now explore our recent BGP Flowspec extensions to the 6WIND vRouter.

Flowspec solutions are available in today’s routers to help customers protect against security threats, such as Distributed Denial of Service (DDoS) attacks, by providing more granular route filtering control on BGP Edge Routers.

Most of us are already familiar with DDoS attacks and how to add static temporary routes to implement blackholing of traffic to endpoints under attack. Essentially, all traffic to a targeted victim is silently discarded by diverting traffic to nowhere (i.e. a blackhole). Blackholing is done in the context of BGP by injecting the prefixes in question into BGP with a community using a next-hop to nowhere (a discard route).

For anybody interested in blackholing, check out RFCs relating to BGP:  RFC3882 and RFC5635 or various blogs on the subject.

 

Flowspec Introduction

Basic blackholing serves the attacker’s original intent, i.e. making the victim unreachable. A better solution to the beforehand mentioned problem is to use BGP Flowspec defined in RFC5575 and RFC7674.

With BGP Flowspec, a much more granular approach is possible, which avoids a total denial of traffic to the victim. Flowspec adds a new Network Layer Reachability Information (NLRI) encoding in order to match traffic on a particular flow with source, destination, packet characteristics (length, protocol type, fragmentation, etc.) and for miscellaneous L4 parameters (TCP flags, UDP/TCP ports, ICMP, and more).

Think of this as a distributed Access Control List (ACL). This conceptual ACL has class and policy-maps information that flows to BGP peers.

6WIND routing has historically been based on the Quagga routing suite. Going forward 6WIND is replacing Quagga with a routing protocol suite based on the FRR protocol suite from www.frrouting.org.

This will ensure that 6WIND keeps providing the best white box vRouter experience based on Open Source technology.

Refer to the following diagram for an overview of the FRR Client.

 

6WIND Flowspec Design Principles

Policy-based routing mechanisms (NetFilter) are used to apply the Flowspec configuration to the underlying 6WIND Linux OS.

The 6WIND vRouter can be configured using either the built-in CLI or standard Linux ipset and iptables commands.

Here is an example that uses standard Linux commands for familiarity rather than the 6WIND CLI. This is a reminder that 6WIND transparently offloads Linux filtering. Ipset is used to create essentially a block of addresses and iptables is used to create a filtering chain matching this block of addresses. Finally a rule is created with a new route for routing table 102 based on this match.

# linux shell

ipset create match0x102 hash:net,net counters

ipset add match0x102 32.0.0.0/16,40.0.0.0/16

iptables -N match0x102 -t mangle iptables -A match0x102 -t mangle -j MARK –set-mark 102 iptables -A match0x102 -t mangle -j ACCEPT

iptables -i ntfp3 -t mangle -I PREROUTING -m set –match-set match0x102 src,dst -g match0x102 ip rule add fwmark 102 lookup 102

ip route add 40.0.0.0/16 via 44.0.0.2 table 102

 

So what happens when Flowspec rules are being received?

For handling an incoming Flowspec entry, the following workflow is applied:

  • Incoming Flowspec entries are handled by the BGP daemon, and are stored in the BGP RIB.
  • A Flowspec entry will be installed according to its complexity.

It will be installed if one of the following filtering actions is seen on the BGP extended community: either redirect IP, or redirect Virtual Routing and Forwarding (VRF), in conjunction with rate option, for redirecting traffic; or when the rate option is set to 0, for discarding traffic.

According to the degree of complexity of the Flowspec entry, it will be installed in the RIB (zebra). The Flowspec entry is split into several parts before being sent to zebra.

  • The zebra daemon receives the policy-routing configuration.

Policy-routing entities necessary to route the traffic in the underlying system are received by zebra. Two filtering contexts will be created or appended (NetFilter ipset and iptable entry). If the traffic has to be dropped, then those filtering contexts will be enough. Otherwise, the traffic will be redirected to another routing table, where in that routing table, a route will redirect the traffic to the new desired destination.

 

6WIND Configuration Guide

In order to configure an IPv4 flowSpec engine, use the following configuration:

# 6WIND CLI

router bgp as <AS>

neighbor <A.B.C.D> remote-as <remoteAS>

address-family ipv4 flowspec

neighbor <A.B.C.D> activate

exit

exit

show routing bgp ipv4 flowspec [detail | A.B.C.D]

 

Sometimes it is desirable to configure Flowspec on a per interface basis rather than on all router interfaces. In fact, not doing so can result in side effects such as double accounting of packets or even slowing down the traffic due to filtering costs.

To limit Flowspec to one specific interface, use the following configuration setting:

 # 6WIND CLI

router bgp as <AS>

address-family ipv4 flowspec

local-install enable <IFNAME | any>

local-install disable <IFNAME | any>

exit

exit

 

By default, Flowspec is activated on all interfaces. Installing it to a named interface will result in allowing only this interface. Enabling ‘any’ interface will flush all previously configured interfaces.

In order to troubleshoot BGP Flowspec, for instance when encountering issues when decoding a Flowspec entry, enable debug bgp flowspec. Also if failing to apply the Flowspec entry into Zebra, look at the policy-based routing mechanism with debug bgp pbr [error].

# 6WIND CLI

log

log-option bgp flowspec | pbr | pbr-error

 

Flowspec Redirect VRF

Often multiple VRF tables are used, each providing a separate routing table independent of other VRFs. BGP Flowspec entries have an extended community that contains a Route Target. The Route Target must be defined for each VRF in order to find the local VRF based on the Route Target.

Each VRF is being configured within a BGP VRF instance with its own Route Target list. Route Target accepted formats match the following: A.B.C.D:U16, or U16:U32, U32:U16.

  • The first VRF with the matching Route Target will be selected as the route destination.

Example:

# 6WIND CLI

router bgp as <AS> vrf vrf-id 2

address-family ipv4 unicast

rt redirect import [Route Target List]

exit

exit

 

In Summary

Flowspec provides rich and complex networking functionality for deeper protection and increased uptime. This functionality keeps evolving as 6WIND continuously updates and adds features in our vRouters to meet customer requirements and demands.

Arbor Networks has been successful to use Flowspec and sFlow in 6WIND vRouters for its Security Training Network. Click here to read the Solution Brief.

Contact us today to discuss how Flowspec and sFlow features in 6WIND’s high performance vRouters can help protect your network.

 


Jes Nielsen is a Solution Engineer for 6WIND.