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

AR500, AR510, AR531, AR550, AR1500, and AR2500 Security Hardening And Maintenance Guide

This document provides guidance for strengthening network and device security in terms of network security risks, security architecture, and security hardening policies. It also provides guidance for routine maintenance of device security in terms of the management, control, and forwarding planes.
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).
MPLS

MPLS

LDP

Security Policy Introduction
  • LDP MD5 authentication

    MD5 is a digest algorithm. A typical MD5 application is to calculate a message digest to prevent message spoofing. The MD5 message digest is a unique result calculated using an irreversible character string conversion. If a message is modified during transmission, a different digest is generated. After the message arrives at the receive end, the receive end can detect the modification after comparing the received digest with a pre-computed digest.

    LDP MD5 authentication prevents LDP packets from being modified by generating the unique summary information for the same information segment, and is stricter than the common check of TCP connections.

    LDB MD5 authentication is performed before LDP messages are sent over TCP. A unique message digest is added behind the TCP header. The message digest is calculated using the MD5 algorithm based on the TCP header, LDP message, and user-defined password.

    When the receiving the message, the receive end obtains the TCP header, message digest, and LDP message. It calculates the message digest based on the obtained information and the password locally saved. Then, it compares the calculated message digest with the message digest carried in the LDP message. If they are different, the recipient considers that the LDP message has been tampered with.

    A password can be set either in cipher text or plain text. If the password is set in plain text, the password set by users is directly recorded in the configuration file. If the password is set in cipher text, the password is encrypted using a special algorithm and then recorded in the configuration file.

    Characters set by users are used in digest calculation irrespective of whether the password is set in plain text or cipher text. Encryption/decryption algorithms are proprietary to vendors.

  • LDP keychain authentication

    Keychain, an enhanced encryption algorithm similar to MD5, calculates a message digest for an LDP message to prevent the message from being modified.

    During keychain authentication, a group of passwords are defined to form a password string, and each password is assigned the encryption and decryption algorithms such as MD5 algorithm and configured with the expiration duration. When sending or receiving a packet, the system selects a valid password based on the user's configuration. Then, within the expiration duration of the password, the system starts the encryption algorithm matching the password to encrypt the packet before sending it out, or starts the encryption algorithm matching the password to decrypt the packet before accepting it. In addition, the system can automatically adopt a new password after the previous password expires, preventing the password from being decrypted.

    The password of keychain authentication, the encryption and decryption algorithms, and the expiration duration of the password can be configured separately on a keychain configuration node. A keychain configuration node at least requires that one password and the encryption and decryption algorithms.

    To reference a keychain configuration node, specify the required peer and the name of the node in the MPLS LDP view. In this manner, an LDP session is encrypted. Multiple peers can reference the same keychain configuration node.

  • LDP GTSM

    LDP GTSM is the application of the GTSM in LDP.

    The GTSM determines whether a packet is valid by checking its TTL. This protects devices against attacks. GTSM for LDP involves applying the GTSM to LDP messages between adjacent devices or devices that are near to each other (based on the number of next hops). In this mechanism, a TTL value range is set. The LDP messages whose TTLs are not within the specified value range are considered as attack packets and therefore discarded.

Attack Method Introduction

N/A

Configuration Guide
  • Configuring LDP MD5 authentication

    LDP authentication can be configured to improve the security of the connection of an LDP session. LDP authentication is configured on LSRs at both ends of an LDP session.

    MD5 authentication can be configured for a TCP connection over which an LDP session is established, improving security. Note that the peers of an LDP session can be configured with different authentication modes, but must be configured with a single password.

    LDP MD5 authentication generates a unique digest for an information segment to prevent LDP packets from being modified. LDP MD5 authentication is stricter than common checksum verification for TCP connections.

    You can configure either LDP MD5 authentication or LDP keychain authentication based on their separate characteristics:

    The MD5 algorithm is easy to configure and generates a single password which can be changed only manually. MD5 authentication applies to the network requiring short-period encryption.

    The keychain algorithm is complex to configure and generates a set of passwords. Keychain authentication allows automatically change of a password based on the configuration. Therefore, keychain authentication is applicable to the network requiring high security.

    NOTE:

    Keychain authentication and MD5 authentication cannot be both configured on a single LDP peer.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      mpls ldp

      The MPLS-LDP view is displayed.

    3. Run:

      md5-password { plain | cipher } peer-lsr-id password

      MD5 authentication is enabled and an authentication password is configured.

      The password can be set in either plain text or cipher text. A plain-text password is a character string that is pre-configured and directly recorded in a configuration file. A cipher text password is a character string that is recorded in a configuration file after being encrypted using a specified algorithm.

      By default, LDP MD5 authentication is not performed between LDP peers.

      NOTE:

      Characters ^#^# and $@$@ are used as the prefix and suffix of passwords with variable lengths. Characters ^#^# are used in a new password and characters $@$@ are used in an existing password. Characters ^#^# or $@$@ cannot be configured together at the beginning and end of a cipher-text password.

      Configuring LDP MD5 authentication leads to reestablishment of an LDP session and deletes the LSP associated with the LDP session.

  • Configuring LDP keychain authentication

    To enhance the security of an LDP session, you can configure keychain authentication for a TCP connection over which an LDP session is created.

    During keychain authentication, a group of passwords are defined to form a password string, and each password is assigned the encryption and decryption algorithms such as MD5 algorithm and SHA-1 and configured with the expiration duration. When sending or receiving a packet, the system selects a valid password based on the user's configuration. Then, within the expiration duration of the password, the system starts the encryption algorithm matching the password to encrypt the packet before sending it out, or starts the encryption algorithm matching the password to decrypt the packet before accepting it. In addition, the system can automatically adopt a new password after the previous password expires, preventing the password from being decrypted.

    You can configure either LDP MD5 authentication or LDP keychain authentication based on their separate characteristics:

    The MD5 algorithm is easy to configure and generates a single password which can be changed only manually. MD5 authentication applies to the network requiring short-period encryption.

    The keychain algorithm is complex to configure and generates a set of passwords. Keychain authentication allows automatically change of a password based on the configuration. Therefore, keychain authentication is applicable to the network requiring high security.

    NOTE:

    Keychain authentication and MD5 authentication cannot be both configured on a single LDP peer.

    Before configuring LDP keychain authentication, configure keychain globally. For the detailed configuration procedure, see Configuration Guide - Security.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      mpls ldp

      The MPLS-LDP view is displayed.

    3. Run:

      authentication key-chain peer peer-id name keychain-name

      LDP keychain authentication is enabled and the name of the configured keychain is referenced.

      By default, LDP keychain authentication is not performed between LDP peers.

      Configuring LDP keychain authentication causes re-establishment of an LDP session and deletes the LSP associated with the deleted LDP session.

  • LDP GTSM

    The LDP GTSM can be configured on LSRs at both ends of an LDP session.

    The GTSM checks TTL values to verify packets and defend devices against attacks. LDP peers are configured with the GTSM and a valid TTL range to check TTLs in LDP packets exchanged between them. If the TTL in an LDP packet is not in the valid range, this LDP packet is considered invalid and discarded. The GTSM defends against CPU-based attacks initiated using a large number of forged packets and protects upper-layer protocols.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      mpls ldp

      The MPLS-LDP view is displayed.

    3. Run:

      gtsm peer ip-address valid-ttl-hops hops

      LDP GTSM is configured.

      If the value of hops is set to the maximum number of valid hops permitted by GTSM, when the TTL values carried in the packets sent by an LDP peer are within the range [255+ 1, 255], the packets are received; otherwise, the packets are discarded.

  • LDP GTSM

    The LDP GTSM can be configured on LSRs at both ends of an LDP session.

    The GTSM checks TTL values to verify packets and defend devices against attacks. LDP peers are configured with the GTSM and a valid TTL range to check TTLs in LDP packets exchanged between them. If the TTL in an LDP packet is not in the valid range, this LDP packet is considered invalid and discarded. The GTSM defends against CPU-based attacks initiated using a large number of forged packets and protects upper-layer protocols.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      mpls ldp

      The MPLS-LDP view is displayed.

    3. Run:

      gtsm peer ip-address valid-ttl-hops hops

      LDP GTSM is configured.

      If the value of hops is set to the maximum number of valid hops permitted by GTSM, when the TTL values carried in the packets sent by an LDP peer are within the range [255–hops+1, 255], the packets are received; otherwise, the packets are discarded.

RSVP

Security Policy Introduction

RSVP transmits packets using RawIP, which does not ensure security. In RawIP, packets are easily tampered with and devices are easily attacked. Digests of RSVP messages are verified to protect the messages against tampering and forgery attacks, enhancing network reliability and security.

  • Basic principle

    The same key must be configured on the two nodes involved in authentication. When sending a packet, a node calculates a digest using the HMAC-MD5 algorithm based on the configured key. The digest is carried in the packet as an integrity object to the peer node. The peer node calculates the digest using the same algorithm based on the configured key, and compares the two digests. If the two digests are the same, it accepts the packet; otherwise, it discards the packet. RSVP authentication, however, cannot prevent the anti-replay attack and solve the problem of neighbor relationship termination resulted from disordered RSVP messages. To solve these problems, RSVP authentication extensions are introduced. The RSVP authentication extensions include the authentication lifetime, authentication handshake mechanism, and sliding window mechanism based on the original authentication mechanism. They can improve the RSVP security and enhance the user authentication in an adverse network environment such as network congestion.

  • RSVP key management modes

    RSVP supports two key management modes:

    • MD5

      Users can enter plain-text or cipher-text keys on RSVP interfaces and neighbors. The key algorithm is MD5. The features of this mode are as follows:

      1. A unique key must be configured for each feature and the key cannot be shared.

      2. An interface or a neighbor can be configured with only one key. To change the key, reconfigure it.

    • Keychain

      Keychain is an enhanced encryption algorithm. It allows users to define a group of passwords as a password string. An encryption/decryption algorithm and a validity period are defined for each password. The system selects a valid password based on the configurations, encrypts packets before sending them, and decrypts packets when receiving them using the encryption/decryption algorithm matching the selected password. In addition, the system can automatically adopt a new password after the previous password expires, preventing the password from being decrypted.

      The features of this mode are as follows:

      1. The password of keychain authentication, the encryption and decryption algorithms, and the expiration duration of the password can be configured separately on a keychain configuration node. A keychain configuration node at least requires that one password and the encryption and decryption algorithms.

      2. Keychain can be referenced by features to implement centralized key management and feature sharing.

      In RSVP, keychain can be referenced on interfaces or neighbors by using the HMAC-MD5 algorithm.

  • RSVP authentication modes

    RSVP supports two authentication modes:

    • Neighbor-oriented authentication

      In this mode, you can configure authentication information such as authentication keys based on different neighbor addresses. RSVP then authenticates each neighbor separately.

      Neighbor-oriented authentication can be configured in two ways:

      1. Configured based on an interface IP address of the neighbor.

      2. Configured based on the LSR ID of the neighbor.

    • Interface-oriented authentication

      f interface-oriented authentication is configured, RSVP authenticates packets based on their inbound interfaces.

    Neighbor-oriented authentication takes precedence over interface-oriented authentication. Packets that fail authentication are discarded. If neighbor-oriented authentication is not enabled, interface-oriented authentication takes effect.

Attack Method Introduction

Common attacks and prevention methods are described as follows:

  • Replay attack

    When processing packets, RSVP checks various information including parameters, formats, and types. The information can be easily obtained by attackers. Therefore, attackers can intercept RSVP packets and send packets to the device repeatedly to increase the load of the device. Object verification is added for RSVP messages to protect the messages against tampering and forgery attacks, enhancing network reliability and security.

  • Error packet attack

    Attackers construct various types of error packets, such as super long packets, packets with wrong headers, packets of wrong lengths, and packets with invalid next hops, to perform attacks. RSVP has strict rules for outgoing packets. It discards error packets without ending neighbor relationships, ensuring service continuity. It does not accept or advertise packets with serious errors, such as super long packets and packets of invalid types.

Configuration Guide
  • Configuring RSVP key authentication

    RSVP key authentication is performed between interfaces of two RSVP neighbors. The keys configured on the interfaces of the two neighbors must be the same; otherwise, authentication fails and the received RSVP packets are discarded.

    Object verification is added for RSVP messages to protect the messages against tampering and forgery attacks, enhancing network reliability and security.

    RSVP key authentication can be configured in the interface view or MPLS RSVP-TE peer view.

    RSVP key authentication configured in the interface view applies to two directly connected nodes. RSVP key authentication configured in the MPLS RSVP-TE peer view applies to any two nodes that are configured as neighbors. RSVP key authentication configured in the MPLS RSVP-TE peer view is recommended.

    HMAC-MD5 or keychain authentication can be configured based on the selected parameter.

    cipher: indicates that HMAC-MD5 authentication is used and the key is displayed in cipher text.

    plain: indicates that HMAC-MD5 authentication is used and the key is displayed in plain text.

    keychain: indicates that keychain authentication is used and the globally configured keychain is referenced.

    NOTE:

    RSVP keychain authentication supports only the HMAC-MD5 algorithm.

    NOTE:

    Characters ^#^# and $@$@ are used as the prefix and suffix of passwords with variable lengths. Characters ^#^# are used in a new password and characters $@$@ are used in an existing password. Characters ^#^# or $@$@ cannot be configured together at the beginning and end of a simple password.

    NOTE:

    Configuration must be completed on the two directly connected interfaces within three update periods. Otherwise, the session becomes down.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      interface interface-type interface-number

      The view of an interface on an MPLS TE link is displayed.

    3. Run:

      mpls rsvp-te authentication { { { cipher | plain } auth-key } | keychain keychain-name }

      The authentication key is configured.

  • Configuring RSVP key authentication in the MPLS RSVP-TE peer view

    NOTE:

    Configuration must be completed on the two neighboring nodes within three update periods. Otherwise, the session becomes down.

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      mpls rsvp-te peer ip-address

      The MPLS RSVP-TE peer view is displayed.

      If ip-address is an interface IP address of the neighbor and is different from the LSR ID of the neighbor, the key authentication is configured based on the neighbor's interface IP address. RSVP authentication configured in this mode is valid only to this interface of the neighbor, and therefore delivers high security and has the highest priority.

      If ip-address is the LSR ID of the neighbor, key authentication is configured based on the LSR ID of the neighbor. Key authentication configured in this mode is valid to all interfaces on the neighbor. The authentication configured in this mode has a lower priority than that configured based on the neighbor's interface IP address but has a higher priority than that configured in the interface view.

    3. Run:

      mpls rsvp-te authentication { { { cipher | plain } auth-key } | keychain keychain-name }

      The authentication key is configured.

  • (Optional) Configuring the TTL of RSVP authentication

    You can configure the duration in which RSVP neighbors can keep a neighbor relationship if no constraint-based routed label switched path (CR-LSP) is available.

    When no CR-LSP is available between RSVP neighbors, they can keep the neighbor relationship until the configured TTL of RSVP authentication elapses. The configured TTL of RSVP authentication does not affect existing CR-LSPs.

    1. Run:

      system-view

      The system view is displayed.

      The interface view or MPLS RSVP-TE peer view is displayed.

    2. Run:

      interface interface-type interface-number

      The view of an interface on an MPLS TE link is displayed. If this command is run in an interface view, the configuration takes effect only on the interface.

    3. Run:

      mpls rsvp-te peer ip-address

      The MSLS RSVP-TE peer view is displayed.

      If ip-address is an interface IP address of the neighbor and is different from the LSR ID of the neighbor, the TTL is configured based on the neighbor's interface IP address. The configured TTL is valid only to the interface.

      If ip-address is the LSR ID of the neighbor, the TTL is configured based on the LSR ID of the neighbor. The configured TTL is valid to all interfaces on the neighbor.

    4. Run:

      mpls rsvp-te authentication lifetime lifetime

      The lifetime for RSVP-TE authentication is configured.

      lifetime specifies the TTL of RSVP authentication. The value is in HH:MM:SS format and ranges from 00:00:01 to 23:59:59. The default value is 00:30:00, that is, 30 minutes.

  • (Optional) Configuring the handshake function

    Before configuring the handshake function, configure RSVP key authentication.

    1. Run:

      system-view

      The system view is displayed.

    2. The interface view or MPLS RSVP-TE peer view is displayed.

      • Run:

        interface interface-type interface-number

        The view of an interface on an MPLS TE link is displayed. If this command is run in an interface view, the configuration takes effect only on the interface.

      • Run:

        mpls rsvp-te peer ip-address

        The MSLS RSVP-TE peer view is displayed.

      • If ip-address is an interface IP address of the neighbor and is different from the LSR ID of the neighbor, the handshake function is configured based on the neighbor's interface IP address. The handshake function is valid only to the interface.

      • If ip-address is the LSR ID of the neighbor, the handshake function is configured based on the LSR ID of the neighbor. The handshake function is valid to all interfaces on the neighbor.

    3. Run:

      mpls rsvp-te authentication handshake local-secret

      The handshake function is configured. local-secret is of only local significance and does not need to be the same as local-secret configured on the peer.

    After the handshake function is configured on the local node, if the local node receives an RSVP message from a neighbor with no RSVP authentication relationships, the local node sends a Challenge message carrying local-secret to this neighbor. The neighbor replies with a Response message carrying the local-secret parameter included in the Challenge message sent from the local node. If local-secret carried in the Response message is consistent with that on the local node, RSVP authentication can be configured between them.

    NOTE:

    If the handshake function is configured among neighbors and the authentication TTL must be configured with the mpls rsvp-te authentication lifetime command, the authentication TTL must be greater than the interval for sending RSVP update messages.

    If the authentication TTL is smaller than the interval for sending RSVP update messages, authentication relationships may be deleted because no RSVP update message is received within the authentication TTL. As a result, the handshake mechanism is applied again when a new update message is received. The traffic engineering (TE) tunnel may be deleted or fail to be established.

  • (Optional) Configuring the message window function

    The message window function resolves packet out-of-sequence problems.

    By default, the size of the RSVP message window is 1. That is, the local device saves the RSVP message with the largest sequence number sent from neighbors.

    When the window size is larger than 1, the local device can save more RSVP messages sent from neighbors.

    1. Run:

      system-view

      The system view is displayed.

    2. The interface view or MPLS RSVP-TE peer view is displayed.

      • Run:

        interface interface-type interface-number

        The view of an interface on an MPLS TE link is displayed. If this command is run in an interface view, the configuration takes effect only on the interface.

      • Run:

        mpls rsvp-te peer ip-address

        The MSLS RSVP-TE peer view is displayed.

      • If ip-address is an interface IP address of the neighbor and is different from the LSR ID of the neighbor, the message window size is configured based on the neighbor's interface IP address. The configured message window size is valid only to the interface.

      • If ip-address is the LSR ID of the neighbor, the message window size is configured based on the LSR ID of the neighbor. The configured message window size is valid to all interfaces on the neighbor.

      • Run the mpls rsvp-te authentication window-size window-size command to configure the message window. The message window specifies the number of neighbor RSVP messages that can be saved on the local device.

      • Before configuring the message window function, configure RSVP key authentication.

      NOTE:

      If the RSVP interface type is Eth-trunk or IP-trunk, only one neighbor relationship can be established among RSVP neighbors on a trunk. RSVP messages can be received from any member interface of the trunk. Packets are not received in sequence on the member interfaces of the trunk. This may cause packet out-of-sequence problems. Therefore, the RSVP message sliding window must be configured. It is recommended that you set the window size to 32. If the window size is too small, some received RSVP messages may be beyond the window size and get discarded, terminating the RSVP neighbor relationships.

Configuration Suggestion

Configure RSVP authentication in the interface view to improve security in packet transmission.

Translation
Download
Updated: 2019-05-06

Document ID: EDOC1000097300

Views: 4822

Downloads: 72

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