Reservation Protocol Traffic Engineering Signalling Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The Resource Reservation Protocol for Traffic Engineering converts paths computed on the basis of network topology into Label Switched Paths. The RSVP­TE is not a routing protocol [3]. RSVEP-TE supports all the functionality of RSVP plus more functionality. Normally, a routing protocol distributes information that nodes use to determine how traffic should be forwarded. A TE signalling protocol, such as RSVP­TE, tell the nodes how to forward traffic. Thus, RSVP­TE encompasses a label distribution protocol and a QoS signalling protocol.

Signalling is usually started at the edge of an MPLS domain and is performed from the egress node to the ingress node along specific traffic­engineered paths [2]. When an ingress node chooses to create an LSP, an initial RSVP­TE Path message (addressed at layer 3) is sent, containing a Label Request Object to the intended egress node. This message is either routed individually at each hop or, in rare cases, is placed on an existing LSP. Most commonly, an Explicit Route Object is placed in the message that explicitly specifies the network path.

3.1.1 RSVP-TE Hello Message

If the node feels a neighbour is being tracked, the node may from time to time, (default value is 5 milliseconds) generate a Hello message containing a Hello Request object for each neighbour whose status is being tracked. For every Hello Request, neighbour must send a Hello Acknowledgment. If no messages are received within a configured number of Hello intervals (default for this is 3.5 intervals), then a node presumes that it cannot communicate with the neighbour. A comparison is also made between the new received values of Source and Destination Instance fields with the values most recently received from every neighbour also with last values send to them. An assumption is now made to show that communication with the peer has been lost too.

3.1.2 RSVP-TE Path Message

The Path message holds the information needed for TE and QoS signalling. Consequently, the message goes through the same path along which traffic will eventually flow. When the egress node receives the Path message, it crafts a Resv message containing a Label Object and any applicable resource reservations, which is sent back along the same path to the ingress node.

Each node in the path creates the right label binding, changes the Label Object with one of its free labels, and addresses (at layer 3) the Resv message to the next node. When the Resv message reaches the ingress node, the LSP is created and all applicable resources are reserved for the flow. Note that the path must be refreshed at regular intervals, typically every 30 seconds. Another important RSVP­TE message is the PathTear message, which tears down LSPs. This message is sent from an ingress node to an egress node to release all path state and associated resource reservations, including label bindings.

3.1.3 RSVP-TE ResvTear Message

After a Resv message is sent, a corresponding ResvTear message follows the same route, releasing resources along the way. The message is generally sent when an egress node wishes to change the reservation parameters for an LSP. Unlike a PathTear message, ResvTear does not delete the associated path state. Even after a ResvTear message travels up an LSP, all the intermediate nodes keep their path state and the ingress node continues to refresh the path. Thus, the LSP is allocated but not usable until the egress node

sends a new Resv message, ostensibly with new reservation parameters.


In a few years from now, most of the global telecommunications and Internet traffic are expected to use Multiprotocol Label Switching (MPLS) networks as a medium of transfer [12]. Most telecommunication technologies are already using this because of the growing trend. Successful attacks on MPLS networks like any other technology could take down a large portion or portions of the information infrastructure. Therefore, the significance of the research of MPLS as a critical infrastructure component is imperative. From the ongoing research known up to now, little, if any, has focused on MPLS security. The RSVP­TE signalling protocol is obviously a well known major concern, this protocol initiates high speed traffic paths in MPLS networks and informs MPLS nodes how to forward traffic.

This project examines the security issues related to RSVP­TE, especially how RSVP­TE objects and messages can be misused in MPLS network attacks. Seven exploits are discussed: two enumeration attacks, two cross domain attacks and three denial of service attacks. Enumeration attacks provide detailed information about network topology and configuration that could be exploited in other attacks. Cross­domain attacks target trust relations that exist between nodes in MPLS networks and nodes in customer networks. Denial of service attacks leverage weaknesses in the RSVP­TE protocol to delay or disrupt traffic. The project concludes by outlining mitigation strategies and security postures.

3.2.1 Exploitations of RSVP for Traffic Engineering

From ongoing research, realising the misuse of RSVP­TE messages, a thorough analysis of RSVP­TE was performed, including its functionality and configuration. Each node element of RSVP­TE was tested in detail for its ability to negatively influence an MPLS network. Protocol objects (e.g., message objects) were studied to ascertain their function under normal conditions. Unsuitable values for these objects were seen and considered with the associated RSVP­TE messages and, then, in the larger context of the MPLS network. The research also showed seven exploits. two enumeration attacks, two cross­domain attacks and three denial of service attacks. The three attack categories and the seven attacks are described in detail in the following sections.


Enumeration, involving network reconnaissance, is usually the first step of a more subtle attack [13]. The two enumeration attacks shown below may be used to obtain thorough information about MPLS network view and setup, which could be exploited in other attacks.

3.3.2 Record Route Object Access

The Record Route Object (RRO) in Path and Resv messages has the record of nodes that have already received the message [2]. Examination of an RRO offers two types of information. Firstly, many (if not all) of the network node addresses are listed in the RRO. Secondly, node adjacency can be established because each node adds its address to the RRO in succession as a message navigates an MPLS network.

The main importance to note is that RROs provide embedded information about the shortest paths in an MPLS network. Vital data typically passes through the shortest available paths. When accessing RROs, attackers can obtain costly information about the paths used for transporting these critical pieces of data, which , later can be intended to cause the serious damage.

3.3.3 Ingress Probing

This kind of attack can also be seen in a port scan in an IP network and in some ways, similar. An entrance point into the MPLS network is first recognised, then, subsequent probing is done to unravel additional information about the network that can be used in attacks.

A Path message, in ingress probing, encapsulated in IP with the Router Alert Option set is sent to a target MPLS node. If a Resv message is obtained, the intended node is an ingress node in the MPLS network. Also, using the Explicit Route Object (ERO), a Path message could be sent to the ingress node with the Router Alert Label at the top of the stack. (The ERO, which is normally employed in traffic engineering to initiate very specific LSPs, holds the node sequence traversed by an RSVP­TE message.) In reply to this Path message, receiving a Resv message indicates that the MPLS network accepts pre­labelled traffic.

This in turn means that objects used in the MPLS network can now be determined. This is done by sending a different Path message with each optional object. An implication that the network accepts the optional object is a response when a Resv message is received. In addition, with the condition that the pre­labelled traffic is received, a Path message with the Router Alert Label on top of the stack is sent for every potential label value. With a condition that a Resv message is accepted, the matching label is valid and may be used in an attack afterwards.


The provider of an MPLS service must permit a trust path from the customer edge (CE) to allow traffic to come in within its network. The two cross­domain attacks shown below utilise the trust relationship which is seen among CE and provider edge (PE) nodes.

3.2.21 Acceptance of Promiscuous Paths

Integrated Services (IntServ) [10] is a Quality of Service architecture which receives a variety of signalling protocols and requires routers and switches to execute traffic policing, admission control, classification, queuing and scheduling. The implementation of the InterServ QoS of a service provider in a traditional switched network often uses RSVP messaging, the predecessor of RSVP­TE used in MPLS networks. In such cases, a PE node in an adjacent MPLS network would accept packets with the Router Alert Option set as specified by the RSVP protocol [7]. Subsequently, Path messages with RSVP­TE objects would be allowed unless they are specifically denied. Once an RSVP­TE message infringes the MPLS domain border, nothing will be able to stop it from being taken to a target.

This exploit of the cross­domain needs an attacker with CE node access to send an RSVP­TE message with the Router Alert Option set to a PE node in a neighbouring MPLS network. An acceptance form the PE node is taken from the RSVP­TE message and is forwarded within the MPLS network. This attack is hazardous because an attacker who has the CE node access may falsify RSVP­TE messages to perform any traffic engineering signalling function of the attacker's choice.

3.2.2 Acceptance of Pre­Labelled Traffic

The configuration of the PE node can be performed to allow labelled traffic from a CE node to be received by the MPLS network. In such circumstances, pre-platform scoping rules are used by the PE nodes, or else the markers sent from the CE node interface would not have any binding. The MPLS network is now exposed when accepting pre­labelled traffic to any number of signalling attacks from a compromised CE node.

An example of an attack can be seen when sending a Path message straight to the PE node with the Router Alert Label on the top of the stack. It should be noted that for this attack to be deemed successful, another label under the Router Alert Label in the stack must be there. Furthermore, the Explicit Route Object could be used to forward the Path message without the label beneath the Router Alert Label. Once this has been achieved, the compromised CE node creates LSPs via RSVP­TE which uses the LSPs to send malicious labelled traffic to the PE node.

A compromised CE node is another attack which sends packets with labels that have been attached to the PE node. The knowledge about the egress node is what this particular attack relies on, which could be obtained using an enumeration exploit. The successful bindings are not obtained until the CE node iterates through the label values. These labels with malicious traffic may then be sent to the PE node, which carries it on to nodes inside the MPLS network.


Denial­of­service (DoS) attacks relentlessly limit network availability. Within this section, there are three attacks which discusses leverage weaknesses in the RSVP­TE protocol to upset legitimate traffic.

3.5.1 Deletion of Label Switched Path

The involvement of this attack is the injection of malicious PathTear messages that eliminate label bindings and resource reservations of targeted LSPs. Crafting a PathTear message could be deemed as a sinister attack involving a specific node in a targeted label switched path. This message has to be re­sent at least once per refresh phase. An attacker who has knowledge of the internet protocol addresses of the ingress and egress nodes, tunnel ID and LSP ID could use these values in the malignant PathTear message. It will cause the receiving node not to allocate resources associated with the LSP (including label bindings) and stop forwarding traffic for the LSP. Resulting traffic intended for the LSP is taken off by the LSRs.

Other traffic is not influenced by the attack, because each LSP can be targeted individually. Also, the attack may not go detected for some time as network administrators might not check how the targeted path was affected. A note should be taken that multiple LSPs could be targeted, inadvertently causing the whole MPLS network to fail.

3.5.2 Exhaustion of Path State Resource

This type of exploit is analogous to the SYN flood attack in IP networks, which gives way to resources by half opening a proportionate number of ports on a TCP host [13]. Each node along the route saves its path state, when a Path message is sent through a network. If the Path message has a Record Route Object (RRO), a copy of the RRO is saved in each node within its path state. For a particular amount of time, the path state is saved i.e. (90 seconds by default). If the link bandwidth is sufficient, sending numerous spoofed Path messages with a considerable amount of RROs may exhaust the memory resources of nodes.

This type of attack incorporates sending a considerable amount of Path messages with an arbitrary egress node address. Each Path message should hold an Explicit Route Object that establishes the target nodes. The size of the RRO should be such that the entire packet size is MTU ô€€€ .RSL _ n/, where MTU is the maximum transmission unit, RSL is the size of an RRO sub­object (e.g., 8 bytes for IPv4 sub­objects), and n is the number of nodes traversed by the Path message. This confirms that each node on the Path message's route will have the utmost amount of path state information. A note should be made that the attack also targets LSR resources and not particular paths. However, all LSPs used by the marked LSRs are affected.

3.5.3 Excessive Allocation of LSP ID

The enabling of RSVP­TE signalling allows one egress node to support up to 216 LSPs per ingress node. In any case, if an association of each LSP with an egress node is systematically torn down, deceitfully rebuilt and the arising label binding hijacked by the attacker, all the LSPs terminating at that egress node may be disorganised.

Fig. 3.0

Figure 3 highlights the pseudo code for this attack. The effort done xhausts label IDs for each ingress node. Nevertheless, an attacker can "DoS" an egress node with respect to a specific ingress node; all LSPs involved with other ingress nodes should not be affected. Plus, an attacker could, however, attempt to choose multiple targets and "DoS" an egress node with respect to multiple ingress nodes. This should interrupt traffic that are aimed while allowing dmagerous or malicious traffic to flow in and out of the network.