Fundamentals

Common Scenarios

Figure 1 Application scenario of the attack defense feature

In the face of attacks from the Internet, DeviceA requires security features to retain the continuous service capability and to maintain proper communication with DeviceB and DeviceC.

Principles

The router implements multi-layer detection on packets to be sent to the CPU in three phases to implement security of the router.
  1. The forwarding plane implements three-level control.

    • Validity check (local URPF, TCP/IP attack defense, and GTSM)

    • Session-level control (dynamic link protection)

    • Board-level control (blacklist, whitelist, and user-defined flow rules, TCP/IP attack defense, TM multi-level scheduling, and application layer association)

  2. The control plane implements two-level control.
    • Interface-based check on the control plane (management plane protection)
    • Detection of invalid packets (TCP/IP attack defense and URPF check)
  3. Recording attack source tracing information
Figure 2 Three-level attack defense control

Implementation

Figure 3 Flowchart for using attack defense to process packets
As shown in the preceding figure, the attack defense feature processes protocol packets as follows:
  1. A device filters out invalid ARP packets and performs URPF check on the packets passing through an interface. If the check is passed, the packets are further processed. If the check fails, the packets are discarded.
  2. Perform microsegmentation CAR check on packets. For traffic of protocol-specific sessions established on different ports, set a bandwidth limit the traffic to be sent to the control plane to isolate the interaction between protocol-specific sessions on different ports. After the microsegmentation CAR check is complete, the device proceeds to the next step.
  3. Host-ACL check is performed on packets. Host-CAR, VLAN-host-CAR, or HTTP-host-CAR is not performed on the packets that match the specified ACL rule. If the packets do not match the specified ACL rule, the device proceeds to the next step.
  4. Host CAR is performed on packets to limit the rate of packets sent from the user side to the CPU. If the check is passed, the packets are further processed. If the check fails, the packets are discarded.
  5. The device performs GTSM check on the packets. If the check is passed, the packets are further processed. If the check fails, the packets are discarded.
  6. The device checks the packets to defend against TCP/IP attacks. If the check is passed, the packets are further processed. If the check fails, the packets are discarded. The device checks packets to defend against TCP SYN flood attacks and IP fragment attacks. If the check is passed, the packets are sent to the CPU through related CPCAR channels and then sent to the control plane at a rate limited using the total CAR function. If the packets do not match any rule, the device goes to the next step.
  7. The device matches the packets against dynamic link protection rules that define traffic characteristics, such as the source IP address, destination IP address, protocol number, source port, destination port, source MAC address, and destination MAC address. If the packets match the rules, they are sent to the CPU through the dynamic-whitelist CPCAR channel and then sent to the control plane at a rate limited using the total CAR function. If the packets do not match any rule, the device goes to the next step.
  8. The device matches packets against the whitelist rules based on 5-tuple information carried in the packets. If the packets match the rules, they are sent to the CPU through the whitelist CPCAR channel and then sent to the control plane at a rate limited using the total CAR function. If the packets do not match any rule, the device goes to the next step.
  9. Each packet is matched against blacklist rules based on 5-tuple information carried in the packet. If a match is found, the packet is discarded. If the packets do not match any rule, the device goes to the next step.
  10. The device matches packets against user-defined flow rules that define traffic characteristics. If the packets match the user-defined flow rules, the device executes the actions defined in the rules for the packet. If the packets are to be sent to the CPU, the device performs CPCAR for the user-defined flow channel and sends the packets to the control plane using the total CAR function. If the packets do not match any rule, the device goes to the next step.
  11. CAR is performed for the traffic of some protocols based on port+VLAN according to the rules configured on the device. If the interface-based CAR is not configured or the interface-based CAR processing is complete, the device goes to the next step.

    When configuring port VLAN CAR, you can specify that the priority of protocol-based port CAR is higher than that of the whitelist, blacklist, and user-defined flow. In this case, packets preferentially match the whitelist, blacklist, or user-defined flow.

  12. CPCAR is performed for protocol packets based on the protocol type, and the packets are sent to the TM module.
  13. After multi-level scheduling is performed, the TM module implements total CAR to limit the rate of all packets to be sent to the control plane, and sends the packets to the control plane for processing.
Parent Topic: Understanding Device Security
Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
Next topic >