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

ME60 V800R010C10SPC500 Feature Description - MPLS 01

This is ME60 V800R010C10SPC500 Feature Description - 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).
RSVP Authentication

RSVP Authentication

Principles

RSVP messages are sent over Raw IP with no security mechanism and expose themselves to being modified and expose devices to attacks. These packets are easy to modify, and a device receiving these packets is exposed 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.

RSVP authentication parameters are as follows:

  • 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 (Keyed-Hashing for Message Authentication)-Message Digest 5 (MD5) algorithm or Secure Hash Algorithm (SHA). 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.

  • 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. If a network flaps, a CR-LSP is deleted and created. During the deletion, the RSVP neighbor relationship associated with the CR-LSP is retained 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.

Key Authentication 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 IP 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.

The keychain key is recommended.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059460

Views: 7308

Downloads: 17

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