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

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.
  

  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

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.