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 - MPLS

S7700 and S9700 V200R013C00

This document describes the configurations of MPLS, including Static LSP, MPLS LDP, MPLS QoS, MPLS TE, MPLS OAM, Seamless MPLS.
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 TE Security

MPLS TE Security

RSVP authentication verifies digest messages carried in RSVP messages to defend against attacks initiated by modified or forged messages. Authentication enhancements can also be used to prevent replay attacks and packet mis-sequencing. RSVP authentication and its enhancements improve MPLS TE network security.

Background

RSVP uses raw IP to transmit packets. Raw IP has no security mechanism and is prone to attacks. RSVP authentication verifies packets using keys to prevent attacks. When the local RSVP router receives a packet with a sequence number smaller than the local maximum sequence number, the neighbor relationship is terminated.

Key authentication cannot prevent replay attacks or neighbor relationship termination resulting from RSVP message mis-sequencing. The RSVP authentication enhancements are used to address these problems. RSVP authentication enhancements add authentication lifetime, handshake, and message window mechanisms to enhance RSVP security. The enhancements also improve RSVP's capability to verify neighbor relationships in a harsh network environment, such as a congested network.

Concepts

  • Raw IP: Similar to User Datagram Protocol (UDP), raw IP is unreliable because it has no control mechanism to determine whether raw IP datagrams reach their destinations.
  • Spoofing attack: An unauthorized router establishes a neighbor relationship with a local router or sends pseudo RSVP messages to attack the local router. (For example, requesting the local router to reserve a lot of bandwidth.)
  • Replay attack: A remote RSVP router continuously sends packets with sequence numbers smaller than the maximum sequence number on a local RSVP router. Then the local router terminates the RSVP neighbor relationship with the remote RSVP router and the established CR-LSP is torn down.

Implementation

  • Key authentication

    RSVP authentication protects RSVP nodes from spoofing attacks by verifying keys in packets exchanged between neighboring nodes. The same key must be configured on two neighboring nodes before they perform RSVP authentication. A local node uses the configured key and the Keyed-Hashing for Message Authentication Message Digest 5 (HMAC-MD5) algorithm to calculate a digest for a message, adds this digest as an integrity object into the message, and then sends the message to the remote node. After the remote node receives the message, it uses the same key and algorithm to calculate a digest and checks whether the local digest is the same as the received one. If they match, the remote node accepts the message. If they do not match, the remote node discards the message.

  • Authentication lifetime

    The authentication lifetime specifies the period during which the RSVP neighbor relationship is retained and provides the following functions:
    • Controls the lifetime of an RSVP neighbor relationship when no CR-LSP exists between the RSVP neighbors. The RSVP neighbor relationship is retained until the RSVP authentication lifetime expires. The RSVP-TE authentication lifetime does not affect the status of existing CR-LSPs.

    • Prevents continuous RSVP authentication. For example, after RSVP authentication is enabled between RTA and RTB, RTA continuously sends tampered RSVP messages with an incorrect key to RTB. As a result, RTB continuously discards the messages. The authentication relationship between neighbors, however, cannot be terminated. The authentication lifetime can prevent this situation. When neighbors receive valid RSVP messages within the lifetime, the RSVP authentication lifetime is reset. Otherwise, the authentication relationship is deleted after the authentication lifetime expires.

  • Handshake mechanism

    The handshake mechanism maintains the RSVP authentication status. After neighboring nodes authenticate each other, they exchange handshake packets. If they accept the packets, they record a successful handshake. If a local node receives a packet with a sequence number smaller than the local maximum sequence number, the local node processes the packet as follows:
    • Discards the packet if it shows that the handshake mechanism is not enabled on the remote node.
    • Discards the packet if it shows that the handshake mechanism is enabled on the remote node and the local node has a record about a successful handshake. If the local node does not have a record of a successful handshake with the remote node, this packet becomes the first to arrive at the local node and the local node starts a handshake process.
  • Message window

    A message window saves the received RSVP messages. If the window size is 1, the system saves only the largest sequence number. If the window size is set to a value greater than 1, the system saves the specified number of largest sequence numbers. For example, the window size is set to 10, and the largest sequence number of received RSVP messages is 80. The sequence numbers from 71 to 80 can be saved if there is no packet mis-sequencing. If packet mis-sequencing occurs, the local node sequences the messages and records the 10 largest sequence numbers.

    When the window size is not 1, the local RSVP node considers the RSVP message received from the neighboring node as a valid message in either of the following situations:
    • The sequence number in the received RSVP message is larger than the maximum sequence number in the window.
    • The RSVP message carries an original sequence number that is larger than the minimum sequence number in the window but is not saved in the window.
    The local RSVP node then adds the sequence number of the received RSVP message to the window and processes the RSVP message. If the sequence number is larger than the maximum sequence number in the window, the local RSVP node deletes the minimum sequence number in the window. If the sequence number is smaller than the minimum sequence number in the window or already exists in the window, the local RSVP node discards the RSVP message.
    NOTE:
    By default, the window size is 1. The handshake mechanism works when the window size is 1. If the window size is not 1, the handshake mechanism is affected. When the local RSVP node receives an RSVP message with a sequence number smaller than the local maximum sequence number, either of the following situations occurs:
    • If the sequence number of the received RSVP message is larger than the minimum sequence number in the window and is not saved in the window, the local RSVP node correctly processes the RSVP message.
    • If the sequence number already exists in the window, the local RSVP node discards the RSVP message.
    • If the sequence number is smaller than the minimum sequence number in the window, RSVP determines whether both ends are enabled with the handshake mechanism. If either one is not enabled with the handshake mechanism, the system discards the RSVP message. If both ends are enabled with the handshake mechanism, the local and remote ends start the handshake process again and discard the RSVP message.

    For example, the window size is 10, and the window stores sequence numbers 71, 75, and 80. If the local RSVP node receives an RSVP message with sequence number 72, it adds the sequence number to the window and correctly processes the RSVP message. If the local RSVP node receives an RSVP message with sequence number 75, it directly discards the RSVP message. If the local RSVP node receives an RSVP message with sequence number 70, RSVP determines whether both ends are enabled with the handshake mechanism. The local and remote ends start the handshake process again only when they are both enabled with the handshake mechanism.

RSVP Key Management Modes

RSVP keys can be managed in either of the following modes:
  • MD5 key

    An MD5 key is entered in either cipher text or plain text. The MD5 algorithm has the following characteristics:
    • Each protocol is configured with a separate key and cannot share a key with another protocol.

    • An interface or a node is assigned only one key. To change the key, you must delete the original key and configure a new one.

  • Keychain key

    Keychain is an enhanced encryption algorithm. It allows you to define a group of passwords to form a password string, and to specify encryption and decryption algorithms and a validity period for each password. When the system sends or receives a packet, the system selects a valid password. Within the validity period of the password, the system uses the encryption algorithm configured for the password to encrypt the packet before sending it out, or the system uses the decryption algorithm configured for the password to decrypt the packet after receiving it. In addition, the system uses a new password after the previous one expires, minimizing the risks of password cracking.

    Keychain has the following characteristics:
    • A keychain authentication password and the encryption and decryption algorithms must be configured. The password validity period can also be configured.

    • Keychain settings can be shared by protocols and managed uniformly.

    Keychain can be used on an RSVP interface or node and supports only HMAC-MD5.

MD5 key cannot ensure key. You are advised to use Keychain key.

RSVP Authentication Modes

RSVP defines the following authentication modes:

  • Neighbor-oriented authentication

    You can configure authentication information, such as authentication keys, based on different neighbor addresses. RSVP then authenticates each neighbor separately.

    A neighbor address can be either of the following:
    • IP address of an interface on an RSVP neighboring node

    • LSR ID of an RSVP neighboring node

  • Interface-oriented authentication

    Authentication is configured on interfaces, and RSVP authenticates messages based on inbound interfaces.

Neighbor-oriented authentication takes precedence over interface-oriented authentication. A node discards messages if neighbor-oriented authentication fails, and performs interface-oriented authentication only if neighbor-oriented authentication is not enabled.

Translation
Download
Updated: 2019-04-08

Document ID: EDOC1100065745

Views: 19946

Downloads: 14

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