RSVP Authentication

Principles

RSVP uses RawIP to transmit protocol packets. RawIP does not provide security. As a result, packets are easily tampered with, and the device is vulnerable to attacks.

RSVP authentication prevents the following situations and improves device security: An unauthorized remote router sets up an RSVP neighbor relationship with the local router. A remote router constructs forged RSVP messages to set up an RSVP neighbor relationship with the local router and initiates attacks (such as maliciously reserving a large number of bandwidths) to the local router.

Key: The same key must be configured on two RSVP nodes before they perform RSVP authentication. A node uses this key to compute a digest for a packet to be sent based on the HMAC-MD5 (Keyed-Hashing for Message Authentication-Message Digest 5) algorithm. The packet carrying the digest as an integrity object is sent to a remote node. After receiving the packet, the remote node uses the same key and algorithm to compute a digest for the packet, and compares the computed digest with the one carried in the packet. If they are the same, the packet is accepted; if they are different, the packet is discarded.

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.

Sequence number: In addition, each packet is assigned a 64-bit monotonically increasing sequence number before being sent, which prevents replay attacks. After receiving the packet, the remote node checks whether the sequence number is in an allowable window. If the sequence number in the packet is smaller than the lower limit defined in the window, the receiver considers the packet as a replay packet and discards it. RSVP authentication also introduces handshake messages. If a receiver receives the first packet from a transmit end or packet mis-sequence occurs, handshake messages are used to synchronize the sequence number windows between the RSVP neighboring nodes.

Authentication lifetime: Network flapping causes an RSVP neighbor relationship to be deleted and created alternatively. Each time the RSVP neighbor relationship is created, the handshake process is performed, which delays the establishment of a CR-LSP. The RSVP authentication lifetime is introduced to resolve the problem. After the RSVP authentication lifetime is configured, the RSVP neighbor relationship is maintained — even if no LSP exists between RSVP neighbors — until the RSVP authentication lifetime expires.

Authentication Key Management

An HMAC-MD5 key is entered in either ciphertext or simple text on an RSVP interface or node. An HMAC-MD5 key has the following characteristics:

• A unique key must be assigned to each protocol.
• A single key is assigned to each interface and node. The key can be reconfigured but cannot be changed.

Authentication Key Configuration Scope

RSVP authentication keys can be configured on RSVP interfaces and nodes.

• Local interface-based key

  A local interface-based key is configured on an interface. The key takes effect on packets sent and received on this interface.

• Neighbor node-based key

  A neighbor node-based key is associated with the label switch router (LSR) ID of an RSVP node. The key takes effect on packets sent and received by the local node.

• Neighbor address-based key

  A neighbor address-based key is associated with the address of an RSVP interface. The key takes effect on the following packets:

  • Received packets with the source or next-hop address the same as the configured one
  • Sent packets with the destination or next-hop address the same as the configured one

On an RSVP node, if the local interface-, neighbor node-, and neighbor address-based keys are configured, the neighbor address-based key takes effect; the neighbor node-based key takes effect if the neighbor address-based key fails; if the neighbor node-based key fails, the local interface-based key takes effect.

A specific RSVP authentication key is configured in a specific situation:

• Neighbor node-key usage scenario: If multiple links or hops exist between two RSVP nodes, only a neighbor node-based key needs to be configured, which simplifies the configuration. Two RSVP nodes authenticate all packets exchanged between them based on the key.

• On a TE FRR network, packets are exchanged on an indirect link between a Point of Local Repair (PLR) node and a Merge Point (MP) node.

• Local interface-based key usage scenario: Two RSVP nodes are directly connected and authenticate packets that are sent and received by their indirectly connected interfaces.

• Neighbor address-key usage scenarios: Two RSVP nodes cannot obtain the LSR ID of each other (for example, on an inter-domain network). The PLR and MP authenticate packets with specified interface addresses.