Configuring RSVP Authentication
Context
RSVP key authentication prevents an unauthorized node from setting up RSVP neighbor relationships with the local node or generating forged packets to attack the local node. By default, RSVP authentication is not configured. Configuring RSVP authentication is recommended to ensure system security.
An unauthorized node attempts to set up a neighbor relationship with the local node.
A remote node generates and sends forged RSVP messages to set up a neighbor relationship with the local node.
RSVP key authentication alone cannot prevent anti-replay attacks or RSVP message mis-sequence during network congestion. RSVP message mis-sequence causes authentication termination between RSVP neighbors. The handshake and message window functions, together with RSVP key authentication, can prevent the preceding problems.
The RSVP authentication lifetime is configured, preventing unceasing RSVP authentication. In the situation where no CR-LSP exists between RSVP neighbors, the neighbor relationship is kept Up until the RSVP authentication lifetime expires.
- Configure RSVP key authentication in the interface view: the RSVP key authentication is performed between directly connected nodes.
- Configure RSVP key authentication in the MPLS RSVP-TE neighbor view: the RSVP key authentication is performed between neighboring nodes, which is recommended.
Perform the following configurations on each node of the MPLS TE tunnel.
The configuration must be complete on two neighboring nodes within three refreshing intervals. If the configuration is not complete on either of the two neighboring nodes after three intervals elapse, the session goes Down.
Procedure
- Run system-view
The system view is displayed.
- Run either of the following commands to enter the interface view or the MPLS RSVP-TE neighbor view:
To enter the interface view of an MPLS TE tunnel, run interface interface-type interface-number
RSVP key authentication configured in the interface view takes effect only on the current interface and has the lowest preference.
On an Ethernet interface, run the undo portswitch command to switch the working mode of the interface to Layer 3 mode.
To enter the MPLS RSVP-TE neighbor view, run mpls rsvp-te peer ip-address
- When ip-address is specified as an interface address but not the LSR ID of the RSVP neighbor, key authentication is based on this neighbor's interface address. This means that RSVP key authentication takes effect only on the specified interface of the neighbor, providing high security. In this case, RSVP key authentication has the highest preference.
- When ip-address is specified as an address equal to the LSR ID of the RSVP neighbor, key authentication is based on the neighbor's LSR ID. This means that RSVP key authentication takes effect on all interfaces of the neighbor. In this case, this RSVP key authentication has the higher preference than that configured in the interface view, but has the lower preference than that configured based on the neighbor interface address.
If a neighbor node is identified by its LSR-ID, CSPF must be enabled on two neighboring devices where RSVP authentication is required.
- Run mpls rsvp-te authentication { { cipher | plain } auth-key | keychain keychain-name }
The authentication key is configured.
HMAC-MD5 or keychain authentication is enabled by configuring one of the following optional parameters:cipher: configures HMAC-MD5 authentication with keys displayed in ciphertext.
plain: configures HMAC-MD5 authentication with keys displayed in plaintext.
keychain: configures keychain authentication by using a globally configured keychain. At present, only HMAC-MD5 authentication is supported.
Note that HMAC-MD5 encryption algorithm cannot ensure security. Keychain authentication is recommended.
- (Optional) Run mpls rsvp-te authentication lifetime lifetime
The RSVP authentication lifetime is set.
lifetime is in the format of HH:MM:SS. The value ranges from 00:00:01 to 23:59:59. By default, the time is 00:30:00, that is, 30 minutes.
RSVP neighbors to remain the neighbor relationship when no CR-LSP exists between them until the RSVP authentication lifetime expires. Configuring the RSVP authentication time does not affect the existing CR-LSPs.
- (Optional) Run mpls rsvp-te authentication handshake
The 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 that is the same as that in the Challenge messages. After receiving the Response messages, the local end checks the identifier carried in the Response messages. If the identifier in the Response messages is the same as the local identifier, the device determines to establish an RSVP authentication relationship with its neighbor.
If you run the mpls rsvp-te authentication lifetime lifetime command after configuring the handshake function, note that the RSVP authentication lifetime must be greater than the interval for sending RSVP refresh messages configured by mpls rsvp-te timer refresh command.
If the RSVP authentication lifetime is smaller than the interval for sending RSVP refresh messages, the RSVP authentication relationship will be deleted because no RSVP refresh message is received within the RSVP authentication lifetime. In such a case, after the next RSVP refresh message is received, the handshake operation is triggered. Repeated handshake operations will cause RSVP tunnels unable to be set up or cause RSVP tunnels to be deleted.
- (Optional) Run mpls rsvp-te authentication window-size window-size
The message window function is configured.
window-size is the number of valid sequence numbers carried in RSVP messages that a device can save.
The default window size is 1, which means that a device saves only the largest sequence number of the RSVP message from neighbors.
When window-size is larger than 1, it means that a device accepts several valid sequence numbers.
If RSVP is enabled on an Eth-Trunk interface, only one neighbor relationship is established on the trunk link between RSVP neighbors. Therefore, any member interface of the trunk interface receives RSVP messages in a random order, resulting in RSVP message mis-sequence. Configuring RSVP message window size prevents RSVP message mis-sequence.
The window size larger than 32 is recommended. If the window size is set too small, the RSVP packets are discarded because the sequence number is beyond the range of the window size, causing an RSVP neighbor relationship to be terminated.
- Run quit
Return to the system view.
- (Optional) Set an interval at which a Challenge message is retransmitted and the maximum number of times that a Challenge message can be retransmitted.
If Authentication messages exchanged between two RSVP nodes are out of order, a node sends a Challenge message to the other one to request for connection restoration. If no reply to the Challenge message is received, the node retransmits the Challenge message at a specified interval. If no reply is received after the maximum number of retransmission times is reached, the neighbor relationship is not restored. If a reply is received before the maximum number of retransmission times is reached, the neighbor relationship is restored, and the number of retransmission times is cleared for the Challenge message.
If the interval at which a Challenge message is retransmitted or the maximum number of times that a Challenge message can be retransmitted does not meet your RSVP authentication success ratio requirement, perform the following configurations: