BGP Flow Specification Fundamentals

Basic Concepts

The BGP Flow Specification function allows BGP Flow Specification routes that carry traffic policies to be transmitted to BGP Flow Specification peers to control attack traffic. Basic concepts related to BGP Flow Specification are as follows:

BGP Flow Specification route: BGP Flow Specification routes are defined in standard protocols. Each BGP Flow Specification route contains BGP network layer reachability information (NLRI) and extended community attributes, which carry traffic filtering rules and actions to be taken on matching traffic.
BGP Flow Specification peer relationship: A BGP Flow Specification peer relationship is established between the device that generates BGP Flow Specification routes and each network ingress to advertise the BGP Flow Specification routes. After receiving the BGP Flow Specification routes, the peer delivers preferred BGP Flow Specification routes to the forwarding plane. The routes are then converted into traffic policies that control attack traffic.

The BGP Flow Specification functions include static and dynamic BGP Flow Specification functions, because Flow Specification routes are generated in different ways. Table 1 describes the comparison between static and dynamic BGP Flow Specification functions.

**Table 1** Comparison between static and dynamic BGP Flow Specification functions
Mode	Usage Scenario
Dynamic BGP Flow Specification	Dynamic BGP Flow Specification is used to control unknown attack traffic. A traffic analysis server is deployed to monitor the network and respond to the detection of attack traffic to improve network security.
Static BGP Flow Specification	Static BGP Flow Specification is used to control known or common attack traffic. BGP Flow Specification routes are manually created based on the characteristics of common attack traffic to prevent common attack traffic.

BGP Flow Specification supports inter-AS transmission. If a BGP Flow Specification peer relationship is established between ingresses of two different ASs, BGP Flow Specification routes can be transmitted to the other AS so that attack traffic is controlled. This function confines attack traffic in a limited scope.

After a BGP Flow Specification peer receives a BGP Flow Specification route with the filtering rule of a destination address, the peer must verify the route. The route is considered valid only if it passes BGP Flow Specification route authentication.

Dynamic BGP Flow Specification

To deploy dynamic BGP Flow Specification, a traffic analysis server is required and a BGP Flow Specification peer relationship must be established between the traffic analysis server and each ingress of the network. As shown in Figure 1, the working process of dynamic BGP Flow Specification includes the following steps:

DeviceD and DeviceC sample traffic and send the traffic sample to the traffic analysis server.
The analysis server checks the traffic sample in accordance with pre-configured rules to identify abnormal traffic.
After identifying abnormal traffic, the server automatically generates a BGP Flow Specification route based on the traffic characteristics and sends the route to the ingress DeviceB.
After receiving the route, DeviceB converts the route into a traffic policy to filter received traffic.

Figure 1 Working process of dynamic BGP Flow Specification

Static BGP Flow Specification

When static BGP Flow Specification is to be deployed, a BGP Flow Specification route must be created manually based on the characteristics of common attack traffic. Also, a BGP Flow Specification peer relationship must be established between the device that generates the BGP Flow Specification route and each ingress on the network. As shown in Figure 2, the working process of static BGP Flow Specification is as follows:

A user configures a BGP Flow Specification route manually on DeviceC and configures a filtering rule and an action based on the characteristics of attack traffic.
The BGP Flow Specification route is advertised to the ingress DeviceB.
After receiving the route, DeviceB converts the route into a traffic policy to filter received traffic.

Figure 2 Working process of static BGP Flow Specification

BGP Flow Specification Route Authentication

BGP Flow Specification route authentication is performed in either of the following modes:

Authentication mode 1: After receiving a BGP Flow Specification route with a destination address specified in a filtering rule, a device checks the validity of the route using rules described in Figure 3. The route is considered valid only if the authentication succeeds.
Authentication mode 2: After receiving a BGP Flow Specification route with a destination address specified in a filtering rule, a device checks the validity of the route by checking whether the AS_Path attribute of the route carries the AS_Set or AS_Sequence field. The route is considered valid only if its AS_Path attribute does not carry the AS_Set or AS_Sequence field.

Authentication mode 2 is controlled using a command. If authentication mode 2 is enabled, it is used preferentially.

If the authentication using mode 2 succeeds, the BGP Flow Specification route is considered valid, and the device does not attempt to authenticate the route using mode 1.
If the authentication using mode 2 fails, the device attempts to authenticate the route using mode 1.

If authentication mode 2 is not enabled, the device attempts to authenticate the route using mode 1.

As mentioned previously, after receiving a BGP Flow Specification route with a destination address specified in a filtering rule, a BGP Flow Specification peer must verify the route. The route is considered valid only if it passes BGP Flow Specification route authentication. Figure 3 shows how BGP Flow Specification authentication works.

Figure 3 BGP Flow Specification authentication rules

As shown in Figure 4, a BGP Flow Specification peer relationship is established between DeviceA and DeviceB. DeviceB receives a BGP Flow Specification route from DeviceA. The route carries a filtering rule to control traffic destined for the IP address 172.16.1.0/24. Then, DeviceB authenticates the route using the following process:

DeviceB searches its IP routing table and finds two unicast routes 172.16.0.0/16 and 172.16.1.0/24. After comparison, DeviceB finds that 172.16.1.0/24 is the optimal unicast route.
DeviceB checks the route 172.16.1.0/24 and finds that it is a BGP route.
The originator of the unicast route is DeviceC and the originator of the BGP Flow Specification route is DeviceA. The BGP Flow Specification route fails to be authenticated because the two originators are different.

Figure 4 BGP Flow Specification route authentication

On the NetEngine 8000 F, BGP Flow Specification route authentication can be disabled. If you want to filter traffic based on a specified address prefix, but the BGP Flow Specification route that carries the filtering rule cannot be authenticated, disable BGP Flow Specification route authentication.

BGP Flow Specification implementation on a private network is similar to that on a public network, except that the BGP Flow Specification peer relationship is a VPN peer relationship and the deployment is different on the private network.