RSVP

Security Policy

RSVP transmits packets using raw IP, which does not ensure security. In raw IP, packets are easily tampered with, and devices can be easily attacked. Digests of RSVP messages are verified to protect them from being tampered with and forgery attacks, enhancing network reliability and security.

Basic principles

The same key must be configured on both nodes involved in authentication. When sending a packet, a node generates a digest using the HMAC-MD5 algorithm based on a configured key. The digest is carried in the packet as an integrity object to the peer node. The peer node generates a 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 replay attacks or handle neighbor relationship termination problems resulting from out-of-sequence RSVP messages. To resolve these issues, RSVP authentication extensions are used. RSVP authentication extensions include the authentication lifetime, authentication handshake mechanism, and sliding window mechanism, in addition to the original authentication mechanism. They can improve RSVP security and enhance user authentication in adverse network environments, such as congested networks.
RSVP key management modes

HMAC-MD5 authentication provides low security. To ensure high security, you are advised to use keychain authentication and a high-security algorithm, such as HMAC-SHA-256.
- HMAC-MD5
  
  Users can enter simple text or ciphertext keys on RSVP interfaces and neighbors. The key algorithm is HMAC-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
  
  A 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, 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 use a new password after the previous password expires, preventing the password from being decrypted.
  
  The features of this mode are as follows:
  1. The keychain authentication password, the encryption and decryption algorithms, and the expiration period of the password can be configured separately on a keychain configuration node. A keychain configuration node requires at least one password and an encryption and decryption algorithm.
  2. A keychain can be referenced by features to implement centralized key management and feature sharing.
    In RSVP, a keychain can be referenced on interfaces or neighbors.
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.
  
  Neighbor-oriented authentication can be configured in either of the following ways:
  
  1. Configured based on an interface IP address of a neighbor.
  
  2. Configured based on the LSR ID of a neighbor.
- Interface-oriented authentication
- If 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 Methods

The most common attacks and prevention methods are as follows:

Replay attacks

When processing packets, RSVP checks various information, including parameters, formats, and types. The information can be easily obtained by attackers. Therefore, attackers can illegally obtain RSVP packets and repeatedly send packets to the device to increase the load of the device. Object verification is added to RSVP messages to protect the messages from being tampered with and forgery attacks, enhancing network reliability and security.
Error packet attacks

Attackers construct various types of error packets, such as super long packets, packets with incorrect headers, packets of incorrect lengths, and packets with invalid next hops, to initiate attacks. RSVP uses 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 extremely long packets or invalid packet types.

Procedure

Configure RSVP key authentication in neighbor address-based mode.
1. Run system-view
  The system view is displayed.
2. Run interface interface-type interface-number
  The view of the interface on which the MPLS TE tunnel is established is displayed.
3. Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }
  The key for RSVP authentication is configured.
  
  HMAC-MD5 or keychain authentication can be configured based on the selected parameter:
  - cipher: HMAC-MD5 authentication is used, and a key is displayed in ciphertext.
  - plain: HMAC-MD5 authentication is used, and a key is displayed in simple text.
  - keychain: Keychain authentication is used, and a globally configured keychain is referenced.
  If you configure a simple password, it will be saved in the configuration file in clear text that has a high security risk. Therefore, configuring a ciphertext password is recommended. To improve the device security, periodically change the password.
  
  HMAC-MD5 authentication provides low security. To ensure high security, you are advised to use keychain authentication and a high-security algorithm, such as HMAC-SHA-256.
  
  Configuration must be complete on the two directly connected interfaces within three update periods. If configuration is not complete after three update periods elapse, the session goes Down.
4. Run commit
  The configuration is committed.
Configure RSVP key authentication in neighbor-based mode.
1. Run system-view
  The system view is displayed.
2. Run mpls
  The MPLS view is displayed.
3. (Optional) Run mpls rsvp-te challenge-lost peer-address
  The maximum number of allowable discarded challenge messages that are sent by the supplicant to the authenticator during RSVP authentication is set.
4. (Optional) Run mpls rsvp-te retrans-timer challenge retransmission-interval
  The interval at which challenge messages are retransmitted is set.
5. Run mpls rsvp-te peer peer-address
  The RSVP neighbor view is displayed.
6. Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }
  The key for RSVP authentication is configured.
  
  HMAC-MD5 or keychain authentication can be configured based on the selected parameter:
  - cipher: HMAC-MD5 authentication is used, and a key is displayed in ciphertext.
  - plain: HMAC-MD5 authentication is used, and a key is displayed in simple text.
  - keychain: Keychain authentication is used, and a globally configured keychain is referenced.
  If you configure a simple password, it will be saved in the configuration file in clear text that has a high security risk. Therefore, configuring a ciphertext password is recommended. To improve the device security, periodically change the password.
  
  HMAC-MD5 authentication provides low security. To ensure high security, you are advised to use keychain authentication and a high-security algorithm, such as HMAC-SHA-256.
  
  Configuration must be complete on the two neighboring nodes within three update periods. If configuration is not complete after three update periods elapse, the session goes Down.
7. Run commit
  The configuration is committed.
(Optional) Configuring RSVP authentication lifetime in the interface view
When no CR-LSP is reachable 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.
2. Run interface interface-type interface-number
  The view of an RSVP-enabled interface is displayed.
3. Run mpls rsvp-te authentication lifetime lifetime
  The RSVP authentication lifetime is set.
4. Run commit
  The configuration is committed.
(Optional) Configuring RSVP authentication lifetime in the MPLS RSVP-TE peer view
1. Run system-view
  The system view is displayed.
2. Run mpls
  The MPLS view is displayed.
3. Run mpls rsvp-te peer peer-addr
  The MPLS RSVP-TE peer view is displayed.
  
  If peer-addr is an interface IP address of the neighbor, not the neighbor LSR ID, key authentication will only take effect on that neighbor interface. Key authentication then provides high security and has the highest priority.
  
  If peer-addr is a neighbor LSR ID, key authentication will take effect on all interfaces on the neighbor. Authentication configured using this method 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.
4. Run mpls rsvp-te authentication lifetime lifetime
  The RSVP authentication lifetime is set.
5. Run commit
  The configuration is committed.
(Optional) Configuring the handshake function in the interface view
The handshake function helps RSVP key authentication prevent replay attacks.
1. Run system-view
  Return to the system view.
2. Run interface interface-type interface-number
  The view of the interface on which the MPLS TE tunnel is established is displayed.
3. Run mpls rsvp-te authentication handshake
  The handshake function is enabled.
  
  The task of "Configuring an RSVP Authentication Mode" must be complete before the RSVP handshake function is configured.
  
  The handshake function helps a device to establish an RSVP neighbor relationship with its neighbor. If a device receives RSVP messages from a neighbor, with which the device has not established an RSVP authentication relationship, the device will send Challenge messages carrying local identifier to this neighbor. After receiving the Challenge messages, the neighbor returns Response messages carrying the identifier the same as that in the Challenge messages. After receiving the Response messages, the local end checks identifier carried in the Response messages. If identifier in the Response messages is the same as the local one, the device determines to establish an RSVP authentication relationship with its neighbor.
4. Run commit
  The configuration is committed.
(Optional) Configuring the handshake function in the MPLS RSVP-TE peer view
1. Run system-view
  The system view is displayed.
2. Run mpls
  The MPLS view is displayed.
3. Run mpls rsvp-te peer peer-addr
  The MPLS RSVP-TE neighbor view is displayed.
  - If ip-address is set to an interface IP address of a neighbor, not the neighbor LSR ID, the handshake function will only take effect on that neighbor interface.
  - If ip-address is set to a neighbor LSR ID, the handshake function will take effect on all interfaces of the neighbor.
4. Run mpls rsvp-te authentication handshake
  The handshake function is enabled.
  
  The task of "Configuring an RSVP Authentication Mode" must be complete before the RSVP handshake function is configured. The handshake can only take effect after it is configured on both ends of an RSVP authentication relationship.
  
  The handshake function helps a device to establish an RSVP neighbor relationship with its neighbor. If a device receives RSVP messages from a neighbor, with which the device has not established an RSVP authentication relationship, the device will send Challenge messages carrying local identifier to this neighbor. After receiving the Challenge messages, the neighbor returns Response messages carrying the identifier the same as that in the Challenge messages. After receiving the Response messages, the local end checks identifier carried in the Response messages. If identifier in the Response messages is the same as the local one, the device determines to establish an RSVP authentication relationship with its neighbor.
5. Run commit
  The configuration is committed.
If the handshake function is configured between neighbors and the lifetime is configured, the lifetime must be greater than the interval at which RSVP update messages are sent. If the lifetime is smaller than the interval at which RSVP update messages are sent, authentication relationships may be deleted because no RSVP update message is received within the lifetime. As a result, the handshake mechanism is used again when a new update message is received. An RSVP-TE tunnel may be deleted or fail to be established.
(Optional) Configuring the message window function in the interface view
The message window function prevents RSVP message mis-sequence.

If the window size is greater than 1, the local device stores several latest valid sequence numbers.
1. Run system-view
  The system view is displayed.
2. Run interface interface-type interface-number
  The view of the interface on which the MPLS TE tunnel is established is displayed.
3. Run mpls rsvp-te authentication handshake
  The handshake function is enabled.
  
  The task of "Configuring an RSVP Authentication Mode" must be complete before the RSVP handshake function is configured. The handshake can only take effect after it is configured on both ends of an RSVP authentication relationship.
4. Run mpls rsvp-te authentication window-size window-size
  The message window function is configured. The value is the number of valid sequence numbers of received RSVP messages that can be stored.
  
  If RSVP is enabled on an Eth-Trunk interface, only one neighbor relationship is established on the trunk interface between RSVP neighbors. This means any trunk member interface receives RSVP messages in a random order, which results in message mis-sequence. An RSVP message window size is configured to address this problem. If the sliding window is too small, received RSVP messages with sequence numbers outside the window size are discarded, which terminates an RSVP neighbor relationship.
5. Run commit
  The configuration is committed.
(Optional) Configuring the message window function in the MPLS RSVP-TE peer view
1. Run system-view
  The system view is displayed.
2. Run mpls
  The MPLS view is displayed.
3. Run mpls rsvp-te peer peer-addr
  The MPLS RSVP-TE peer view is displayed.
  - If peer-addr is set to an interface IP address of a neighbor, not the neighbor LSR ID, the message window size will only take effect on that interface of the neighbor.
  - If peer-addr is set to a neighbor LSR ID, the message window size will take effect on all interfaces of the neighbor.
4. Run mpls rsvp-te authentication handshake
  The handshake function is enabled.
  
  The task of "Configuring an RSVP Authentication Mode" must be complete before the RSVP handshake function is configured. The handshake can only take effect after it is configured on both ends of an RSVP authentication relationship.
5. Run mpls rsvp-te authentication window-size window-size
  The message window function is configured. The value is the number of valid sequence numbers of received RSVP messages that can be stored.
  
  If RSVP is enabled on an Eth-Trunk interface, only one neighbor relationship is established on the trunk interface between RSVP neighbors. This means any trunk member interface receives RSVP messages in a random order, which results in message mis-sequence. An RSVP message window size is configured to address this problem. If the sliding window is too small, received RSVP messages with sequence numbers outside the window size are discarded, which terminates an RSVP neighbor relationship.
6. Run commit
  The configuration is committed.