No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Feature Description - Security 01

This is NE40E V800R010C10SPC500 Feature Description - Security
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding BGP Flow Specification

Understanding BGP Flow Specification

BGP Flow Specification Fundamentals

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. The following basic concepts related to BGP Flow Specification will help you better understand the feature:
  • 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 filtered 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 that will transmit 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 4-3 shows the comparison between static and dynamic BGP Flow Specification functions.
Table 4-3 Static and dynamic BGP Flow Specification functions comparison

Function

Usage Scenario

Dynamic BGP Flow Specification

Dynamic Flow Specification is used to filter out or control unknown attack traffic. A third-party traffic analysis server is deployed to monitor the network and respond to attack traffic to ensure proper network security.

Static BGP Flow Specification

Static Flow Specification is used to filter out or control known or common attack traffic. A BGP Flow Specification route is generated based on traffic characteristics to protect the network against the known or common attack traffic.

NOTE:

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 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 4-1, the working process of dynamic BGP Flow Specification includes the following steps:
  1. Device D and Device C sample traffic and send the traffic sample to the traffic analysis server.
  2. The analysis server checks the traffic sample based on pre-configured rules to identify abnormal traffic.
  3. After identifying abnormal traffic, the server generates a BGP Flow Specification route based on the traffic characteristics and sends the route to the ingress Device B.
  4. After receiving the route, Device B converts the route into a traffic policy to filter received traffic.
Figure 4-1 Working process of dynamic BGP Flow Specification

Static BGP Flow Specification

To deploy static BGP Flow Specification, a BGP Flow Specification route must be generated 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 in the network. As shown in Figure 4-2, the working process of static BGP Flow Specification includes the following steps:
  1. A user generates a BGP Flow Specification route manually on Device C and configures a filtering rule and an action based on the characteristics of the attack traffic.
  2. The BGP Flow Specification route is advertised to the ingress Device B.
  3. After receiving the route, Device B converts the route into a traffic policy to filter received traffic.
Figure 4-2 Working process of static BGP Flow Specification

BGP Flow Specification Route Authentication

BGP Flow Specification routes are authenticated as follows:
  • Authentication mode 1: After receiving a BGP Flow Specification route with a destination address as the filtering rule, the device checks the validity of the route using the rules described in Figure 4-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 as the filtering rule, the 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 specified in the command, 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 specified in the command, the device attempts to authenticate the route using mode 1.

As mentioned previously, after receiving a BGP Flow Specification route with a destination address as the 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 4-3 shows how BGP Flow Specification authentication works.

Figure 4-3 BGP Flow Specification authentication rule

As shown in Figure 4-4, a BGP Flow Specification peer relationship is established between Device A and Device B. Device B receives a BGP Flow Specification route from Device A. The route carries a filtering rule to control traffic destined to the IP address 172.5.1.0/24. Then, Device B authenticates the route using the following process:
  1. Device B searches its IP routing table and finds two unicast routes: 172.5.0.0/16 and 172.5.1.0/24, with the latter as the optimal route.

  2. Device B checks the route 172.5.1.0/24 and learns that it is a BGP route.

  3. The initiator of the unicast route is Device C and the initiator of the BGP Flow Specification route is Device A. The BGP Flow Specification route fails to be authenticated because the two initiators are different.

Figure 4-4 BGP Flow Specification route authentication

NOTE:

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

NOTE:

The basic principles of BGP VPN Flow Specification are similar to those of BGP Flow Specification and are not described here.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055047

Views: 12706

Downloads: 31

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next