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

ME60 V800R010C10SPC500 Configuration Guide - IP Routing 01

This is ME60 V800R010C10SPC500 Configuration Guide - IP Routing
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).
Improving BGP Security

Improving BGP Security

To improve BGP network security, you can configure BGP authentication and GTSM on the BGP network.

Usage Scenario

By performing authentication for BGP peer connections and configuring BGP GTSM, you can improve BGP network security.

  • MD5 authentication

    BGP uses TCP as the transport protocol and considers a packet valid if the source address, destination address, source port, destination port, and TCP sequence number of the packet are correct. However, most parameters in a packet are easily accessible to attackers. To protect BGP against attacks, configure MD5 authentication for TCP connections established between BGP peers.

    To prevent the MD5 password set on a BGP peer from being decrypted, update the MD5 password periodically.

  • Keychain authentication

    A keychain consists of multiple authentication keys, each of which contains an ID and a password. Each key has a lifecycle, and keys are dynamically selected based on the life cycle of each key. After a keychain with the same rules is configured on the two ends of a BGP connection, the keychains can dynamically select authentication keys to enhance BGP attack defense.

  • BGP GTSM

    The GTSM mechanism protects a router by checking whether the TTL value in an IP packet header is within a pre-defined range, which enhances the system security.

  • BGP RPKI

    Resource Public Key Infrastructure (RPKI) improves BGP security by validating the origin ASs of BGP routes.

NOTE:

GTSM supports only unicast addresses. Therefore, configure GTSM on all the routers configured with routing protocols.

Pre-configuration Tasks

Before configuring BGP security, complete the following tasks:

Configuration Procedures

Perform one or more of the following configurations as required.

Configuring MD5 Authentication

In MD5 authentication, an Message Digest 5 (MD5) authentication password is set for a TCP connection, and the MD5 authentication is performed by TCP. If authentication fails, no TCP connection will be established.

Procedure

  • Configuring MD5 Authentication.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run peer { ipv4-address | group-name } password { cipher cipher-password | simple simple-password }

      The MD5 authentication password is set.

      An MD5 authentication password can be set in either a ciphertext or plaintext.

      • cipher cipher-password indicates that a password is set using a ciphertext string.

      • simple simple-password indicates that a password is set using a plaintext string.

      NOTE:
      • The new password is at least eight characters long and contains at least two of upper-case letters, lower-case letters, digits, and special characters.

      • When configuring an authentication password, select the ciphertext mode because the password is saved in configuration files in simple text if you select the simple text mode, which has a high risk. To ensure device security, change the password periodically.

      • When this command is used in the BGP view, it is also applicable to the extended address family view because they use the same TCP connection.

      • BGP MD5 authentication and BGP keychain authentication are mutually exclusive.

    4. Run commit

      The configuration is committed.

Checking the Configurations

Run the following command to check the previous configuration.

  • Run the display bgp peer [ ipv4-address ] verbose command to view the authentication information about BGP peers.

# Run the display bgp peer [ ipv4-address ] verbose command to view the authentication information about BGP peers.

<HUAWEI> display bgp peer verbose
BGP Peer is 10.1.1.2,  remote AS 100
         Type: IBGP link
         BGP version 4, Remote router ID 10.1.1.2

  Group ID : 1
         BGP current state: Established, Up for 00h00m39s
         BGP current event: RecvUpdate
         BGP last state: Established
         BGP Peer Up count: 3
         Port: Local - 179        Remote - 30404
         Configured: Active Hold Time: 180 sec   Keepalive Time:60 sec
         Received  : Active Hold Time: 180 sec
         Negotiated: Active Hold Time: 180 sec   Keepalive Time:60 sec
         Peer optional capabilities:
         Peer supports bgp multi-protocol extension
         Peer supports bgp route refresh capability
         Peer supports bgp 4-byte-as capability
         Address family IPv4 Unicast: advertised and received
 Received: Total 229 messages
                  Update messages                5
                  Open messages                  3
                  KeepAlive messages             221
                  Notification messages          0
                  Refresh messages               0
 Sent: Total 236 messages
                  Update messages                5
                  Open messages                  4
                  KeepAlive messages             225
                  Notification messages          2
                  Refresh messages               0
 Authentication type configured: MD5
 Last keepalive received: 2010-09-20 14:41:10
 Minimum route advertisement interval is 15 seconds
 Optional capabilities:
 Route refresh capability has been enabled
 4-byte-as capability has been enabled
 Peer Preferred Value: 0
 Routing policy configured:
 No routing policy is configured

Configuring Keychain Authentication

After a keychain with the same rules is configured on the two ends of a BGP connection, the keychain can dynamically select the authentication keys to enhance BGP attack defense.

Procedure

  • Configuring Keychain Authentication.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run peer { ipv4-address | group-name } keychain keychain-name

      Keychain authentication is configured.

      To ensure the setup of a TCP connection and BGP exchange between on both ends of a BGP connection, configure keychain authentication specified for TCP-based applications and the same password and encryption algorithms on both ends.

      keychain-name specified in this command must exist; otherwise, the TCP connection cannot be established. For keychain configuration details, see the "Keychain Configuration" chapter in HUAWEI ME60 Configuration Guide - Security.

      NOTE:
      • When this command is used in the BGP view, it is also applicable to the extended address family view because they use the same TCP connection.

      • BGP MD5 authentication and BGP keychain authentication are mutually exclusive.

    4. Run commit

      The configuration is committed.

Checking the Configurations

Run the following command to check the previous configuration.

  • Run the display bgp peer [ ipv4-address ] verbose command to view the authentication information about BGP peers.

# Run the display bgp peer [ ipv4-address ] verbose command to view the authentication information about BGP peers.

<HUAWEI> display bgp peer verbose
BGP Peer is 10.1.1.2,  remote AS 100
         Type: IBGP link
         BGP version 4, Remote router ID 10.1.1.2

  Group ID : 1
         BGP current state: Established, Up for 03h34m24s
         BGP current event: RecvKeepalive
         BGP last state: Established
         BGP Peer Up count: 2
         Port: Local - 23089        Remote - 179
         Configured: Active Hold Time: 180 sec   Keepalive Time:60 sec
         Received  : Active Hold Time: 180 sec
         Negotiated: Active Hold Time: 180 sec   Keepalive Time:60 sec
         Peer optional capabilities:
         Peer supports bgp multi-protocol extension
         Peer supports bgp route refresh capability
         Peer supports bgp 4-byte-as capability
         Address family IPv4 Unicast: advertised and received
 Received: Total 225 messages
                  Update messages                3
                  Open messages                  2
                  KeepAlive messages             220
                  Notification messages          0
                  Refresh messages               0
 Sent: Total 228 messages
                  Update messages                3
                  Open messages                  2
                  KeepAlive messages             222
                  Notification messages          1
                  Refresh messages               0
 Authentication type configured: Key-Chain(abc)
 Last keepalive received: 2010-09-20 14:38:59
 Minimum route advertisement interval is 15 seconds
 Optional capabilities:
 Route refresh capability has been enabled
 4-byte-as capability has been enabled
 Peer Preferred Value: 0
 Routing policy configured:
 No routing policy is configured

Configuring BGP GTSM

BGP GTSM must be configured on both peers.

Usage Scenario

GTSM prevents attacks through TTL detection. An attacker simulates real BGP packets and sends the packets in a large quantity to the ME device. After receiving the packets, an interface board of the ME device directly sends the packets to the BGP module of the control plane if the interface board finds that the packets are sent by the local ME device, without checking the validity of the packets. The control plane of the ME device needs to process the "legal" packets. As a result, the system becomes abnormally busy and the CPU usage is high.

GTSM protects the ME device by checking whether the TTL value in an IP packet header is within a pre-defined range to enhance the system security.

NOTE:
  • GTSM supports only unicast addresses; therefore, GTSM must be configured on all the ME devices configured with routing protocols.

Pre-configuration Tasks

Before configuring the BGP GTSM, complete the following task:

Perform the following steps on both BGP peers:

Procedure

  1. Configure the basic BGP GTSM functions.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run peer { group-name | ipv4-address } valid-ttl-hops [ hops ]

      The BGP GTSM is configured.

      The valid TTL range of detected packets is [255 - hops + 1, 255]. For example, for an EBGP direct route, the number of hops is 1, that is, the valid TTL value is 255. By default, the valid TTL range is [1, 255], that is, the value of hops is 255.

      NOTE:
      • When being configured in the BGP view, GTSM is also applicable to MP-BGP VPNv4 extensions because they use the same TCP connection.
      • The GTSM and EBGP-MAX-HOP functions both affect the TTL values of sent BGP messages and they conflict with each other. Thus, for a peer or a peer group, you can use only either of them.

      A BGP router that is enabled with GTSM checks the TTL values in all BGP packets. As required by the actual networking, packets whose TTL values are not within the specified range are discarded. If GTSM is not configured on a BGP router, the received BGP packets are forwarded if the BGP peer configuration is matched. Otherwise, the received BGP packets are discarded. This prevents bogus BGP packets from consuming CPU resources.

    4. Run commit

      The configuration is committed.

  2. Set the default action for packets that do not match the GTSM policy.

    GTSM only checks the TTL values of packets that match the GTSM policy. Packets that do not match the GTSM policy can be allowed or dropped. If "drop" is set as the default GTSM action for packets, you need to configure TTL values for all the packets sent from valid peers in the GTSM policy. If TTL values are not configured for the packets sent from a peer, the device will discard the packets sent from the peer and cannot establish a connection to the peer. Therefore, GTSM enhances security but reduces the ease of use.

    You can enable the log function to record packet drop for troubleshooting.

    Perform the following configurations on the GTSM-enabled ME device:

    1. Run system-view

      The system view is displayed.

    2. Run gtsm default-action { drop | pass }

      The default action for packets that do not match the GTSM policy is configured.

      NOTE:

      If the default action is configured but no GTSM policy is configured, GTSM does not take effect.

      This command is supported only on the Admin-VS and cannot be configured in other VSs. This command takes effect on all VSs.

    3. Run commit

      The configuration is committed.

Checking the Configurations

Run the following command to check the previous configurations.

  • Run the display gtsm statistics { slot-id | all } command to check the statistics about GTSM.

    NOTE:

    This command is supported only on the Admin-VS.

Run the display gtsm statistics command. Then, you can view the statistics about GTSM, including the numbers of protocol packets, the number of packets that are allowed to pass through, and the number of dropped packets. For example:

<HUAWEI> display gtsm statistics all
GTSM Statistics Table
---------------------------------------------------------------
SlotId  Protocol   Total Counters  Drop Counters  Pass Counters
---------------------------------------------------------------
2       BGP                    18              0             18
2       BGPv6                   0              0              0
2       OSPF                    0              0              0
2       LDP                     0              0              0
2       OSPFv3                  0              0              0
2       RIP                     0              0              0
---------------------------------------------------------------

Configuring RPKI

Resource Public Key Infrastructure (RPKI) is used to secure BGP by validating the origin ASs of BGP routes.

Usage Scenario

When an RPKI server is available on the network and you want to validate the origin ASs of BGP routes, configure RPKI on a client to accept only the routes that originate from the specified ASs. In addition, you can apply the validation result to BGP route selection to ensure that hosts in the local AS can securely communicate with hosts in other ASs.

For the RPKI function to take effect, you need to start RPKI and configure RPKI session parameters and apply the BGP origin AS validation result to route selection.

Pre-configuration Tasks

Before configuring RPKI, configure basic BGP functions.

Procedure

  • Start RPKI and configure RPKI session parameters on a client.
    1. Run system-view

      The system view is displayed.

    2. Run rpki

      RPKI is started, and the RPKI view is displayed.

    3. Run session ipv4-address

      An address of the RPKI server is specified for TCP connections to be set up between the client and RPKI server.

    4. Run tcp port-number [ password md5 cipher-password ]

      A port number and authentication password are configured for TCP connections to be set up between the client and RPKI server.

      NOTE:
      • The new password is at least eight characters long and contains at least two of the following types: upper-case letters, lower-case letters, digits, and special characters.

      • For security purposes, you are advised to configure a password in ciphertext mode. To further improve device security, periodically change the password.

    5. (Optional) Run timer { aging aging-time | refresh refresh-time }

      Timers are configured for the RPKI session between the client and the RPKI server.

      aging-time specifies the aging time of validation information, and refresh-time specifies the interval at which validation information is updated. You can configure the two timers to achieve the desired level of BGP security. If stronger BGP security is desired, configure a small value for each timer. Note that frequent validation information updates will lead to higher bandwidth resource consumption.

    6. (Optional) Run rpki-limit limit [ alert-only | idle-forever | idle-timeout times ]

      The maximum number of Route Origination Authorization (ROA) entries that the device is allowed to receive from an RPKI session is configured.

      In most cases, a large number of ROA entries are saved on an RPKI server. If the device receives a a large number of ROA entries from the RPKI server, excessive system resources will be consumed. In this situation, run the rpki-limit command to configure the maximum number of ROA entries that the device is allowed to receive from an RPKI session.

    7. Run commit

      The configuration is committed.

      NOTE:

      After configuring RPKI session parameters, run the reset rpki session command to reset the RPKI session for the new RPKI session parameters to take effect.

  • Apply the BGP origin AS validation result to route selection.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run prefix origin-validation enable

      BGP origin AS validation is enabled.

      After BGP origin AS validation is enabled, the client periodically queries Route Origin Authorizations (ROAs) from the RPKI server and matches the origin AS of each received BGP route against the ROAs. The validation result can be Valid, Not Found, or Invalid.

      NOTE:

      Run the display rpki table command to view the Route Origin Authorizations (ROAs).

    4. Run bestroute origin-as-validation [ allow-invalid ]

      The BGP origin AS validation result is applied to route selection.

      BGP selects routes in the order of Valid, Not Found, and Invalid. If allow-invalid is not specified in the command, BGP ignores the routes with the validation result being Invalid during route selection.

    5. Run peer { ipv4-address | group-name } advertise origin-as-validation

      The BGP origin AS validation result is advertised to the specified BGP peer or peer group.

    6. Run commit

      The configuration is committed.

Checking the Configurations

Run the display rpki session ipv4-address verbose command to check RPKI session configurations.

<HUAWEI> display rpki session 1.2.3.4 verbose
  RPKI server is 1.2.3.4, port 8282
  RPKI current state: Established, Age: 04s
    VPN-instance name: _public_
    Local host: 1.2.3.1, Local port: 51979
    Remote host: 1.2.3.4, Remote port: 8282
  Refresh time : 180
  Aging time : 3600
  Session ID : 23100
  Serial number : 8
  Session Statistics:
    IPv4 record : 5
    IPv6 record : 3
Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059437

Views: 20540

Downloads: 15

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