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

Configuration Guide - IP Routing 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 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 BGP4+ Security

Improving BGP4+ Security

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

Usage Scenario

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

  • MD5 authentication

    BGP4+ 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 BGP4+ against attacks, configure MD5 authentication for TCP connections established between BGP4+ peers.

    To prevent the MD5 password set on a BGP4+ 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 BGP4+ connection, the keychains can dynamically select authentication keys to enhance BGP4+ attack defense.

  • BGP4+ GTSM

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

  • BGP4+ RPKI

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

NOTE:

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

Pre-configuration Tasks

Before configuring BGP4+ security, configure basic BGP4+ functions.

Configuration Procedures

Perform one or more of the following configurations as required.

Configuring BGP4+ Authentication

BGP4+ authentication can be configured to enhance security of BGP4+ networks.

Usage Scenario

BGP4+ authentication includes:
  • MD5 authentication

    BGP4+ 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 BGP4+ against attacks, configure MD5 authentication for TCP connections established between BGP peers.

    To prevent the MD5 password set on the BGP4+ peers 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.

NOTE:

By default, authentication is not configured for BGP4+. Configuring authentication is recommended to ensure system security.

BGP4+ MD5 authentication and BGP keychain authentication are mutually exclusive.

Pre-configuration Tasks

Before configuring BGP4+ authentication, configure basic BGP4+ functions.

Procedure

  1. Configure MD5 authentication.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

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

      The MD5 authentication password is set.

      In BGP4+ MD5 authentication, you only need to set MD5 authentication passwords for TCP connections, and the authentication is performed by TCP. If the authentication fails, the TCP connections cannot be established.

      An MD5 authentication password can be set by typing a cipher or plain string.

      • cipher cipher-password indicates that a password is set by typing a cipher string.

      • simple simple-password indicates that a password is set by typing a simple string.

      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.

    4. Run commit

      The configuration is committed.

  2. Configure keychain authentication.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run peer { group-name | ipv6-address } 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 NE device Configuration Guide - Security.

    4. Run commit

      The configuration is committed.

Checking the Configuration

# A peer relationship can be set between two peers that have the same authentication information. Check the peer relationship status.

[~HUAWEI] display bgp ipv6 peer
 BGP local router ID : 2.2.2.2
 Local AS number : 65009
 Total number of peers : 3                 Peers in established state : 3
  Peer            V    AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  2001:db8:9:1::2 4 65009        8        9     0 00:05:37 Established       2
  2001:db8:9:3::2 4 65009        2        2     0 00:00:09 Established       2
  2001:db8:10::2  4 65008        9        7     0 00:05:38 Established       2

Configuring the BGP4+ GTSM

BGP4+ GTSM must be configured on both peers.

Usage Scenario

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

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

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

Pre-configuration Tasks

Before configuring the BGP4+ GTSM, complete the following task:

Perform the following steps on both BGP4+ peers:

Procedure

  1. Configure the basic BGP4+ 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 | ipv6-address } valid-ttl-hops [ hops ]

      The BGP4+ 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, the 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 BGP4+ messages and they conflict with each other. Thus, for a peer or a peer group, you can use only either of them.

      A BGP4+ router that is enabled with GTSM checks the TTL values in all BGP4+ 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 BGP4+ router, the received BGP4+ packets are forwarded if the BGP4+ peer configuration is matched. Otherwise, the received BGP4+ packets are discarded. This prevents bogus BGP4+ 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 NE:

    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.

      By default, packets that do not match the GTSM policy are forwarded.

      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 all command to check the statistics about the GTSM.

    NOTE:

    This command is supported only on the Admin-VS.

Run the display gtsm statistics command. Then, you can view the statistics about the 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
---------------------------------------------------------------
0       BGP                    18              0             18
0       OSPF                    0              0              0
0       LDP                     0              0              0
0       OSPFv3                  0              0              0
0       RIP                     0              0              0
---------------------------------------------------------------

Configuring RPKI

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

Usage Scenario

When an RPKI server is available on the network and you want to validate the origin ASs of BGP4+ routes, you can 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 BGP4+ 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 BGP4+ origin AS validation result to route selection.

Pre-configuration Tasks

Before configuring RPKI, configure basic BGP4+ functions.

Procedure

  1. 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 (RPKI) ipv6-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 (RPKI) 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.

    5. (Optional) Run timer (RPKI) { 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 BGP4+ security. If stronger BGP4+ security is desired, configure a small value for each timer. Note that frequent validation information updates will lead to higher bandwidth resource consumption.

      By default, the value of aging-time is 3600s, and the value of refresh-time is 1800s. Retaining the default values is recommended.

    6. 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.

  2. Apply the BGP4+ 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

      BGP4+ origin AS validation is enabled.

      After BGP4+ 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 BGP4+ 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 BGP4+ origin AS validation result is applied to route selection.

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

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

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

    6. Run commit

      The configuration is committed.

Checking the Configurations

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

<HUAWEI> display rpki session 2001:db8:189::202 verbose
  RPKI server is 2001:db8:189::202, port 8282
  RPKI current state: Established, Age: 04s
    VPN-instance name: _public_
    Local host: 2001:db8:189::251, Local port: 51979
    Remote host: 2001:db8:189::202, 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-14

Document ID: EDOC1100058916

Views: 33930

Downloads: 49

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