3.1 SECURITY ANALYSIS OF RSVP-TE SIGNALLING
In a small number of years from now, most of the global telecommunications and Internet traffic are expected to use Multiprotocol Label Switching networks as a medium of transfer [Johnson 2007]. The majority of telecommunication providers are already in full deployment of the next generation MPLS technology on purpose to achieve cut-edge functionalities and support the growing trend.
Regrettably, any successful attack on RSVP-TE path signalling of a typical MPLS network similar to other networks could be disastrous to a large extent or even bring down part of the infrastructure. Thus, there is need for adequate research into security implementation, as such this project investigates RSVP-TE signalling protocol which is relatively of significant integral of the MPLS infrastructure for Label switched path. From the ongoing research known up to now, little, if any, has focused on MPLS security. The RSVPTE 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.
Get your grade
or your money back
using our Essay Writing Service!
This thesis investigates some of the various security exploits of RSVPTE, particularly how RSVPTE signalling protocol objects and messages could be exploited to launch attacks on multiprotocol label switching networks. 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. Crossdomain attacks target trust relations that exist between nodes in MPLS networks and nodes in customer networks. Denial of service attacks leverage weaknesses in the RSVPTE protocol to delay or disrupt traffic. The project concludes by outlining mitigation strategies and security postures.
3.1 RESOURCE RESERVATION PROTOCOL FOR TRAFFIC ENGINEERING (RSVP-TE).
The Resource Reservation Protocol for Traffic Engineering (RSVPTE) converts paths computed on the basis of network topology into Label Switched Paths. The RSVPTE is not a routing protocol . 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 RSVPTE, tell the nodes how to forward traffic. Thus, RSVPTE 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 trafficengineered paths . When an ingress node chooses to create an LSP, an initial RSVPTE 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 ms) 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 RSVPTE 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.2 RSVP-TE ResvTear Message
Always on Time
Marked to Standard
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.
3.2 EXPLOITATIONS OF RSVP-TRAFFIC ENGINEERING
From ongoing research, realising the misuse of RSVPTE messages, a thorough analysis of RSVPTE was performed, including its functionality and configuration. Each node element of RSVPTE 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 RSVPTE messages and, then, in the larger context of the MPLS network.
The research also showed seven exploits . two enumeration attacks, two crossdomain attacks and three denial of service attacks. The three attack categories and the seven attacks are described in detail in the following sections.
3.2.1 Enumeration Attacks
Enumeration, involving network reconnaissance, is usually the first step of a more subtle attack . 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.
188.8.131.52 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 . 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.
184.108.40.206 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 RSVPTE message.) Receiving a Resv message in response to this Path message indicates that the MPLS network accepts prelabelled traffic.
Objects used in the MPLS network can then be determined. This is accomplished by sending a separate Path message with each optional object. Receiving a Resv message in response implies that the network accepts the optional object. Additionally, if prelabelled traffic is accepted, a Path message with the Router Alert Label on top of the stack is sent for every possible label value. If a Resv message is received, the corresponding label is valid and may be used in a later attack.