1

Intrusion Detection Using Protocol-based Non-Conformance to Trusted Behaviors

Vikram Ramakrishnan, R. Anil Kumar and Sherin John Computer Networks & Software, Inc.

7405 Alban Station Court, Suite B-215 Springfield, VA 22150

705-644-2103

Abstract Generalized Multiple Protocol Label

Switching (GMPLS) extends Multi Protocol Label Switching (MPLS) to provide the control plane for use with high speed/bandwidth switching networks. The control plane protocols are vulnerable to attacks both from outside and within the network. SigSec™ 1, an intrusion detection system under development, is intended to help detect and protect against attacks and is based on the premise that the GMPLS management, signaling and routing protocols are similar to programming languages. A protocol can be compared to a language definition: it contains a vocabulary, syntax definition and semantics. Like any computer language the protocol language must be unambiguous. The protocol specifies the behavior of concurrently executing processes. This concurrency creates a new class of subtle issues. One technique to address these issues is the finite state machine (FSM). SigSec captures the signaling protocol messages and forwards them to the appropriate protocol analyzer in addition to saving them to a database. SigSec performs intrusion detection through multiple layers of checks and verifications. SigSec detects many known attacks that may pass through semantic and syntax analyzers. Results of the security attack profile analysis indicate that SigSec is capable of protecting the control plane against any number of attack profiles.

Introduction Generalized Multiple Protocol Label

Switching (GMPLS) extends Multi Protocol Label

1 SigSec™ is a trademark of Computer Networks And Software Inc.

Switching (MPLS) to provide the control plane for devices that can switch packet, time, wavelength, and fiber domains. These techniques are emerging for use in high bandwidth networks similar to SONET. This common control plane promises to simplify network operation and management by automating end-to-end provisioning of connections, managing network resources, and providing the level of QoS that is expected in the new, sophisticated application. To do this the control plane utilizes a suite of protocols, including LMP, RSVP-TE, OSPF-TE, BGP, CR-LDP, IS-IS.

The control plane protocols are vulnerable to attacks both from outside and within the network. SigSec, an intrusion detection system being developed by CNS, Inc under a DOE-SBIR Phase II project, is intended to help detect and protect against such attacks. These attacks my include Denial of Service attacks, Spoofing, and Message Modification. SigSec is not intended to detect virus or firewall breaches resulting in loss of privacy. SigSec relies on analysis of message syntax, semantics and the transitions that may occur in the protocol finite state machine as a result of the receipt of the message.

GMPLS Overview GMPLS defines control plane architecture for

multiple technologies and types of network elements. Since data paths established using GMPLS potentially carry high volumes of data and consume significant network resources, security mechanisms are required to safeguard the underlying network against attacks on the control plane and/or unauthorized usage of data transport resources. The GMPLS control plane should therefore include mechanisms that prevent or minimize the risk of attackers being able to inject and/or snoop on control traffic. These risks depend

1-4244-1216-1/07/$25.00 ©2007 IEEE.

2

on the level of trust between nodes that exchange GMPLS control messages, as well as the realization and physical characteristics of the control channel

Security mechanisms typically are geared towards providing authentication and confidentiality. Authentication can provide origin verification, message integrity and replay protection, while confidentiality ensures that a third party cannot decipher the contents of a message. In situations where GMPLS deployment requires primarily authentication, the respective authentication mechanisms of the GMPLS component protocols may be used. Additionally, the IPSec suite of protocols may be used to provide authentication, confidentiality or both, for a GMPLS control channel. IPSec thus offers the benefits of combined protection for all GMPLS component protocols. A related issue is that of the authorization of requests for resources by GMPLS-capable nodes. Authorization determines whether a given party, presumably already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control, for example by setting limits on the total bandwidth available to some parties in the presence of users, types of resources and sophistication of authorization rules. After authenticating requests, control elements should match them against the local authorization policy. These control elements

must be capable of making decisions based on the identity of the requester, as verified cryptographically and/or topologically.

Even with all the security mechanisms available today, the risk of service disruption increases by not securing the GMPLS control plane with the right type of security mechanism. For example, the triggering of recovery actions under false failure indication messages can destabilize the core network. Such information could subsequently trigger initiation of "false" recovery actions when there are no reasons to do so. The consequences of such actions are unpredictable and may lead to de-synchronization between the control and data plane and also increase the risk of mis-connections. This may lead to possible delivery of the traffic to the wrong destination. In addition, since the control channel between a pair of Link Management Protocol (LMP) nodes may pass through an arbitrary IP cloud, it is important to be able to authenticate the messages that are received over this channel. To see why this is necessary, consider the denial of service that could be caused by sending a fake LMP BeginVerify message to a core optical switch, instructing it to begin verification of its entire data links. If the link verification proceeded, normal data forwarding would be suspended for the duration of the testing.

Figure 1:GMPLS Architecture

3

GMPLS Architecture

GMPLS 1 is based on the IP routing and addressing models. This assumes that IPv4 and/or IPv6 addresses are used to identify interfaces but also that traditional (distributed) IP routing protocols are reused. The common control plane promises to simplify network operation and management by automating end-to-end provisioning of connections, managing network resources, and providing the level of QoS that is expected in the new applications.

Traditional MPLS is designed to carry Layer 3 IP traffic using established IP-based paths and associating these paths with arbitrarily assigned labels. These labels can be configured explicitly, or be dynamically assigned by means of a protocol like Label Distribution Protocol (LDP) or the Resource Reservation Protocol (RSVP).

GMPLS is based on the IP routing and addressing models. This assumes that IPv4 and/or IPv6 addresses are used to identify interfaces but also that traditional (distributed) IP routing protocols are reused. The common control plane promises to simplify network operation and management by automating end-to-end provisioning of connections, managing network resources, and providing the level of QoS that is expected in the new applications.

Traditional MPLS is designed to carry Layer 3 IP traffic using established IP-based paths and associating these paths with arbitrarily assigned labels. These labels can be configured explicitly, or be dynamically assigned by means of a protocol like Label Distribution Protocol (LDP) or the Resource Reservation Protocol (RSVP). GMPLS generalizes MPLS in that it defines labels for switching varying types of Layer 1, Layer 2, or Layer 3 traffic. GMPLS nodes can have links with one or more of the following switching capabilities:

• Fiber-switched capable (FSC) • Lambda-switched capable (LSC) • Time division multiplexing (TDM)

switched capable (TSC) • Packet-switched capable (PSC)

Label-switched paths (LSPs) must start and end on links with the same switching capability. For example, routers can establish packet-switched LSPs with other routers. The LSPs might be carried over a TDM-switched LSP between Synchronous Optical Network (SONET) add/drop multiplexers (ADMs), which in turn might be carried over a lambda-switched LSP. To establish LSPs, GMPLS uses the following mechanisms: • An out-of-band control channel and a data

channel—RSVP messages for LSP setup are sent over an out-of-band control network. Once the LSP setup is complete and the path is provisioned, the data channel is up and can be used to carry traffic. The Link Management Protocol (LMP) is used to define and manage the data channels between a pair of nodes.

• RSVP-TE is already designed to signal the setup of packet LSPs. This has been extended for GMPLS to be able to request path setup for various kinds of LSPs (non-packet) and request labels like wavelengths, time slots, and fibers as label objects.

• Bidirectional LSPs—Data can travel both ways between GMPLS devices over a single path, so non-packet LSPs are signaled to be bidirectional.

Why GMPLS General Multi-protocol Label Switching

(GMPLS) offers a potential alternate approach to provision light paths. GMPLS is considered a superset of MPLS, as it extends the forwarding and controls planes to include not only packet mode and cell mode but also synchronous optical network (SONET), DWDM, and fiber based network elements. GMPLS based converged networks present both challenges and opportunities. The challenges arise from managing a single network built with multiple technologies that support multiple competing services and classes of users. The opportunities include a more efficient network, providing different classes of services sharing the same set of resources, and lower management costs, due to one unified control infrastructure. The intelligent control plane enables the automated management, control and optimization of the converged network.

4

An important economic impact of GMPLS is the ability to automate network resource management and service provisioning of end-to-end traffic engineering paths. Service provisioning has been a manual, lengthy and costly process. The deployment of GMPLS-based nodes allows carriers to automate the provisioning and management of network and promises to lower the cost of operation by several orders of magnitude (days or even minutes instead of weeks or months).

GMPLS Control Plane Protocols Routing Protocols

GMPLS routing is required for dissemination of reachability, topology, and resource/capability information throughout the control plane routing topology. GMPLS provides additional Traffic Engineering (TE) routing extensions to MPLS-TE for non-PSC capable interfaces. For enhanced scalability, the following mechanisms have been defined: unnumbered links, link bundles, and Forwarding Adjacencies. The two suggested protocols for routing are OSPF and IS-IS.

IS-IS-TE

IS-IS-TE 2 is also an intra-domain routing protocol widely used especially in DCN optical network. Besides the classic advantages of other routing protocols (e.g. dynamic, adaptive, loop free...), IS-IS has the ability to perform both OSI and IP (IPv4 and IPv6) routing. This is very convenient considering the current process of migration from OSI to IP that implies the mix of IP and OSI routers. Strong with this long lasting experience on field, ISIS has been elected by IETF as a GMPLS protocol and thus becomes a reference for next generation control plane.

Message encryption methods are available and prevent a number of attacks; however, the encryption methods are not secure against certain insider attacks. Protecting the routing protocols not only protect the infrastructure against inside attacks but also against accidental mis-configurations. ‘SigSec’ aims at providing OSPF TE and ISIS-TE security against attacks based on non-conformance to protocol mechanism. It also provides a set of known attack profiles that essentially identifies the type of attack. SigSec also provides capabilities to extend the ‘attack profile set’ as new attacks are identified.

OSPF-TE

OSPF-TE 3 refers to the standard OSPF protocol plus all its TE related extensions. TE related extensions to OSPF involve advertisement of additional link state information such as available bandwidth for every link in the network. OSPF’s opaque Link State Advertisements (LSA) mechanism is used to extend OSPF to disseminate optical resource related information through optical LSAs. Standard link-state database flooding mechanisms are used for distribution of optical LSAs. The OSPF packets are carried over a single IP control channel between adjacent OXCs.

Traffic demand patterns clearly play a role in determining the frequency of TE related link state advertisements. If the frequency of such advertisements is very low, the information available in every routers link state database can become very stale. It has been shown that stale information may limit the benefits of richer network connectivity. It has also been suggested that in order to capitalize on dense network topologies, link state updates should be more frequent and various techniques exists for dealing with excessive link state traffic.

BGP

The Border Gateway Protocol (BGP) 4 is an inter-autonomous system routing protocol BGP is used to exchange routing information for the Internet and is the protocol used between Internet service providers (ISP). BGP performs three types of routing: interautonomous system routing, intra-autonomous system routing, and pass-through autonomous system routing. BGP is a very robust and scalable routing protocol as evidenced by the fact that it is the routing protocol used for the Internet. When running BGP inside an Autonomous system it is referred to as Internal BGP or IBGP. When run between AS’s it is called EBGP or external BGP

BGP neighbors or peers are established by manual configuration between routers to create a TCP session on port 179. A BGP speaker establishes a session with a BGP peer using an OPEN message to negotiate session parameters. Once a Session is established BGP speaker sends periodic KeepAlive messages to ensure the session is maintained in the absence of Update messages.

5

BGP peers exchange routing messages through the use of Update messages. These updates include Network Layer Reachablity Info and also routes that have been withdrawn. The BGP peers use this information to build their routing tables.

Label Distribution Protocol

GMPLS uses the two protocols defined for MPLS-TE: RSVP-TE and CR-LDP. These protocols are capable of transporting the required LSP parameters such as bandwidth, type of signal, desired link protection, position in a particular multiplex, etc.

CR-LDP: Constraint-Based LSP Setup using Label Distribution Protocol (CR-LDP)

LDP 5 operates by reserving resources in the forward direction and uses TCP as its transport protocol. LDP has been extended to support Traffic Engineering, named as Constraint-Based LSP Setup using LDP. CR-LDP defines a set of TLV structures to support explicit routed signaling, traffic parameters, LSP set-up/holding priority, etc.

At first, LDP discovers its peers by multicasting an LDP Hello message onto the network. The nodes running LDP that receive messages are triggered to establish an LDP session with each other. After session is successfully created, they become LDP peers, and the session is maintained. Then the LDP peers can exchange label distribution messages. If there is any error during label distribution, the LDP Notification messages are used to provide error information, which could tear down the LDP session between LDP nodes. LDP uses TCP as the reliable transport mechanism to deliver all messages except LDP Hello message, which uses UDP.

The label distribution can occur by hop-by-hop or explicit routing. Explicit routing involves the pre-establishment of an intended LSP path prior to signaling. Hop-by hop CR_LDP downstream-on-demand label distribution operates by reserving the resources in the forward direction one segment at a time towards the destination. First, the source will attempt to send traffic to the destination through the ingress LER. The ingress will generate a Label Request message and distribute it to the adjacent LSRs. If an adjacent LSR accepts the Label Request

message and can allocate the requested resources, it will do so and forward the Label Request message to its adjacent LSR in the direction of the destination. Once the Label Request message is accepted by the egress LER, it will generate a Label Mapping message and forward it back to the LSRs toward the source. When the LSRs receive the Label Mapping message, they will compare the Label ID located in both the Label Request message and Label Mapping message, and if it matches, the LSRs will add the label to their forwarding table and forward the Label Mapping message to the next adjacent LSR in the direction of the source. When the ingress LER receives the Label Mapping message, it will perform the Label ID comparison and add the label to its forwarding table as well. Finally, the label is attached to the packets and the traffic is forwarded through the GMPLS network along the predefined LSP. When the traffic reaches the egress LER, the label is removed and the traffic is delivered to the destination.

RSVP-TE

RSVP-TE 6is used to establish MPLS LSPs when there are traffic-engineering requirements. It is mainly used to provide QoS and load balancing across the network core, and includes the ability to control all-optical networks.

RSVP allows the use of source routing where the ingress router determines the complete path through the network. The ingress router can use a Constrained Shortest Path First (CSPF) calculator to determine a path to the destination, ensuring that any QoS and Shared Risk Link Group (SRLG) requirements are met. The resulting path is then used to establish the LSP.

The originator of a multicast packet stream sends out a Tspec as part of a Path message which informs receives of the multicast stream, and intermediate nodes of the traffic requirements of the stream (bandwidth / delay/ etc). The intermediate nodes process this information and forward it along towards the end node along with information about the resources it can allocate to the stream. The end node returns a reservation message to reserve the resources for that LSP. This reservation is maintained using refresh messages. If a refresh is not received for a certain timeout period the reservation is torn down. The reservation is also torn down on receipt of a

6

ResvTear message which signals that the reservation is no longer in used and may resources that were allocated for it may be released.

Link Management Protocol (LMP) The LMP7 specification covers the following

areas of functionality:

• Control Channel Management. This covers the establishment, configuration and maintenance of an IP control channel between a pair of neighboring LMP nodes.

• Link Verification. This covers the verification of connectivity of data links, together with dynamic determination of the mapping between local and remote interface IDs. If link verification is not supported, these mappings must be provided by configuration.

• Link Property Correlation. This is confirmation between neighboring nodes that the mappings between local and remote interface IDs,

and the aggregation of multiple data links into Traffic Engineering (TE) links are consistent.

• Fault Management. Light paths typically traverse multiple data links going from ingress to egress. When this light path fails, LMP provides a way to localize which data link has failed.

• Authentication. This provides cryptographic confirmation of the identity of the neighboring node.

• Security Vulnerabilities

As with any other implementation of networking protocols, security vulnerabilities exist that leave the network susceptible to attacks from both outside and within the network. Some of these vulnerabilities are described in this section.

Figure 2:Security Vulnerabilities

Generic DoS on the Router

A typical attack is to overload a router using various techniques, e.g., by sending traffic exceeding the router's forwarding capacity, sending special transit packets that go through a "slow-path" processing (such functions may also come with problems of their own [BLOCKED], or by sending some packets directed at the router itself

(e.g., to exceed the input queue for CPU processing).

Generic DoS on a Link

Overloading the capacity of a link is often more difficult to prevent than a router DoS. Traffic is typically not automatically rerouted and even if it was, doing so could make the issue worse unless there is ample spare capacity.

7

Cryptographic Exhaustion Attacks

A special form of DoS is attacks that target a protocol which uses cryptographic mechanisms, for example TCP-MD5 or IPsec. The attacker sends valid protocol messages with cryptographic signatures or other properties to the router, which is forced to perform cryptographic validation of the message. If the cryptographic operations are computationally expensive, the attack might succeed easier than with other generic DoS mechanisms.

Unauthorized Neighbor or Routing Attacks

Unauthorized nodes can obtain a routing protocol adjacency on links where an IGP has been enabled by misconfiguration, or where authentication is not used. This may result in many different kinds of attacks, for example traffic redirection.

At least in theory, while it may not be possible to establish an adjacency from outside the link, it may be possible to inject packets as if the adjacency had been established

Unauthorized Neighbor or Routing Attacks

Unauthorized nodes can obtain a routing protocol adjacency on links where an IGP has been enabled by misconfiguration, or where authentication is not used. This may result in many different kinds of attacks, for example traffic redirection.

At least in theory, while it may not be possible to establish an adjacency from outside the link, it may be possible to inject packets as if the adjacency had been established.

Protocols such as BGP and MSDP that process routing information from untrusted, external sources may also be attacked, for example by an unauthorized advertisement of a prefix.

Special care needs to be made to ensure that unauthorized neighbors are prevented (e.g., by regular configuration audits and OSPF protocol filtering at borders). On the other hand, routing attack threats from valid neighbors can be slightly mitigated via appropriate route filtering.

Summary of Present Day Prevention Techniques

Threats posed by the vulnerabilities summarized in the preceding section may be mitigated using tools/methods that are commonly available to today’s network engineers.

Firewall A firewall is an information technology (IT)

security device or program that is configured to permit, deny or proxy data connections set and configured by the organization's security policy. Firewalls can either be hardware and/or software based.

A firewall's basic task is to control traffic between computer networks with different zones of trust. Typical examples are the Internet which is a zone with no trust and an internal network which is (and should be) a zone with high trust. The goal is to provide controlled interfaces between zones of differing trust levels through the enforcement of a security policy and connectivity model based on the least privilege principle and separation of duties.

PKI Public Key Infrastructure (PKI) arrangements

enable computer users to be authenticated to each other, and to use the information in identity certificates (i.e., each other's public keys) to encrypt and decrypt messages traveling to and fro. In general, a PKI consists of client software, server software such as a certificate authority, hardware and operational procedures. A user may digitally sign messages using his private key, and another user can check that signature (using the public key contained in the signer's certificate issued by a certificate authority within the PKI). This enables two (or more) communicating parties to establish confidentiality, message integrity and user authentication without having to exchange any secret information in advance.

Virus Protection techniques Antivirus software consists of computer

programs that attempt to identify, thwart and eliminate computer viruses and other malicious software (malware).

8

Antivirus software typically uses two different techniques to accomplish this:

• Examining (scanning) files to look for known viruses matching definitions in a virus dictionary

• Identifying suspicious behavior from any computer program that might indicate infection. Such analysis may include data captures, port monitoring and other methods.

Most commercial antivirus software uses both of these approaches, with an emphasis on the virus dictionary approach.

IPSec IPsec (IP security) is a suite of protocols for

securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet in a data stream. IPsec also includes protocols for cryptographic key establishment.

IPsec protocols operate at the network layer, layer 3 of the OSI model. Other Internet security protocols in widespread use, such as SSL and TLS, operate from the transport layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it can be used for protecting both TCP- and UDP-based protocols, but increases its complexity and processing overhead.

TLS Transport Layer Security (TLS) and its

predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same. The term "TLS" as used here applies to both protocols unless clarified by context.

The TLS protocol(s) allow applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications privacy over the Internet using cryptography. Typically, only the server is

authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (be that a person, or an application such as a web browser), can be sure with whom they are "talking". The next level of security—in which both ends of the "conversation" are sure with whom they are "talking"—is known as mutual authentication. Mutual authentication requires public key infrastructure (PKI) deployment to clients.

A SigSec Approach GMPLS Specification documents lack an

explicit description of a security frame work to ensure the integrity and security of the control plane transactions.

We propose to use a framework as described in Figure 3. Using “Off the Shelf” components such as firewalls, virus scanners, and passwords, all the standard every day threats may be mitigated. Unfortunately there is always the risk that firewalls may be compromised, virus scanners bypassed and passwords hacked or obtained through social engineering. This leaves us with the task of detecting or preventing the hijack or modification of the messages passed in the control plane from attacks that have managed to pass through the preceding standard layers of security.

The security framework to protect GMPLS control plane is based on the premise that the GMPLS management, signaling and routing protocols are similar to programming languages. A protocol is an agreement about the exchange of information in a distributed system and the protocol definition can be compared to a language definition: it contains a vocabulary and a syntax definition; the procedure rules collectively define a grammar; and the service specification defines the semantics of the language. Like any computer language the protocol language must be unambiguous. Unlike most programming languages, however, the protocol language specifies the behavior of concurrently executing processes. This concurrency creates a new class of subtle issues. One of the techniques to address these issues is to use the finite state machine.

9

Figure 3. Control Plane Security Mechanisms

The Message Capture subsystem of SigSec captures the signaling protocol messages and forwards them to the appropriate protocol analyzer subsystems in addition to saving them to a database. The LMP,

LDP, RSVP-TE, OSPF and IS-IS protocol analyzer subsystems use the protocol message format database, syntax, semantic techniques and the finite state machine to detect valid and invalid messages.

Figure 4. SigSec System

10

SigSec™ performs Intrusion Detection through multiple layers of checks and verifications. The first and most basic check is the check for the authenticity and integrity of individual packets. This is accomplished by ensuring that the packet is valid as per the protocol specifications for the syntactic correctness of the corresponding message packet. SigSec™ verifies the correctness of the message header and proceeds to verify the validity of each of the succeeding fields. Along with verifying field lengths, SigSec™ checks to see that the value contained within the field is semantically correct by checking if it is within permissible ranges for that particular field. It may also check dependant sub-fields of the message to ensure that the intended receiver will parse the message accurately without errors. Any inconsistencies detected here trigger an alert to indicate a potential intrusion into the system. For example, if a BGP peer receives a message that contains a syntax error or an error in its header, intended or inadvertent, it will respond with an error notification and shutdown the session with the peer from whom the bad message was received and will flush all routes learned from that peer. SigSec™ can prevent such disruptions from occurring.

‘SigSec Core’ detects many known attacks that may pass through semantic and syntax analyzers

We have identified a number of potential attacks that can be detected by our strategy. The attacks have also been classified based on system Impact levels and so far 54 have been classified as High to Critical.

Type Of Attack

Total Number Detectable*

(Numbers may change as study progresses)

Denial Of Service 60

Protocol Exploitation 10

Man In the Middle 6

Impersonation 7

Table 1: Attacks Detectable

Once the message is declared Syntactically and Semantically correct, it is passed to the SigSec™ FSM engine. The FSM Engine tracks the State of the corresponding protocol based on the type of the incoming message. This change in state is compared to a set of legal state changes that are allowed by the protocol Finite State Machine, any bad state changes are treated as indicative of an attack or potential attack. A bad state change maybe triggered by the receipt of a message that is not expected by the system in its current state causing the system to crash, reset itself or some such disruptive action.

Unknown attacks are detected through unexpected protocol exchanges/state changes. Results of the security attack profile analysis indicate that SigSec™ is capable of protecting the control plane against any number of attack profiles. SigSec™ can send alerts to control and monitoring system and can provide data logging.

11

Figure 5. LMP Intrusion Detection and Prevention Technique

Figure 5 shows the detection and prevention technique used by the LMP subsystem. LDP, RSVP-TE, OSPF and IS-IS subsystems use similar technique to detect and prevent attacks on the control plane.

Email Addresses Vikram Ramakrishnan

vikram.ramakrishnan@cnsw.com

R. Anil Kumar

Anil.kumar@cnsw.com

Sherin John

Sherin.john@cnsw.com

Acknowledgement This work was supported by the Department of Energy under Small Business Innovation Research Phase II Grant DE-FG02-05ER84386.

Conference Identification 2007 ICNS Conference

1-3 May 2007

12

References 1 Mannie,E , October 2004, Generalized Multi-Protocol Label Switching (GMPLS) Architecture RFC 3945, The Internet Society. 2 Smit, H, June 2004, Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) RFC 3784, The Internet Society. 3 Kazt, D, K.Kompella, September 2003, Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 3630, The Internet Society. 4 Rekhter, Y, T. Li, S. Hares, January 2006, A Border Gateway Protocol 4 (BGP-4) RFC 4271, The Internet Society. 5 Andersson, L, P. Doolan, N. Feldman, A. Fredette, B. Thomas, January 2001, LDP Specification RFC 3036, The Internet Society. 6 Awduche, D, Et Al, December 2001, RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3209, The Internet Society. 7 Lang, J, October 2005, Link Management Protocol (LMP)RFC 4204, The Internet Society.

Boscher, C, L. Wu, E. Gray, January 2002, LDP State Machine RFC 3215, The Internet Society.

Berger, L, January 2003, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description RFC 3271, The Internet Society.

Ashwood-Smith, P, L. Berger, January 2003, Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions RFC 3472, The Internet Society.

Savola, P, January 16, 2007,Backbone Infrastructure Attacks and Protections, IETF Trust.