Security Issues of BGP in Complex Peering and Transit Networks

Transcription

1 Technical Report IDE-0904 Security Issues of BGP in Complex Peering and Transit Networks Presented By: Supervised By: Muhammad Adnan Khalid Qamar Nazir Olga Torstensson Master of Computer network engineering Halmstad University Department IDE Dec

2 Acknowledgement First of all we would like to thanks Halmstad University who provide us a platform to complete this project. Also we would like to thanks our supervisor Olga Torstensson for her encouragement and help throughout the project. 2

3 Abstract Border Gateway Protocol (BGP) is a critical routing protocol of the internet, used to exchange routing information between autonomous systems (ASes). BGP is highly vulnerable to many attacks that can cause routing disturbance on the internet. This paper describes BGP attacks, misconfigurations, causes of misconfigurations, impact of these attacks and misconfigurations in BGP and counter measures. Also we analyze new security architectures for BGP, comparison of these security protocols and their deployment issues. At the end we propose new security solution that is Defensive Routing Policy (DRP) to prevent BGP from malicious attacks and misconfigurations. DRP is operationally deployable and very effective to solve BGP problems. 3

4 Table of Contents Acknowledgement 2 Abstract.. 3 Table of contents.4 1 Introduction Motivation Goals Method Background BGP BGP Path Attributes BGP Messages BGP Misconfiguration and Attacks Misconfiguration Origin Misconfiguration Export Misconfiguration Solution to Avoid Misconfiguration BGP Attacks and Countermeasures Objective of Attacker BGP Attacks Counter Measures Evaluate BGP Security protocols Security Protocols S-BGP SoBGP Pretty Secure BGP Comparison of S-BGP, SoBGP and PsBGP Deployment issue of BGP security protocols Defensive Routing Policy Peer Authentication Managing Customers and Neighbours Route Filtering Filtering Recommendation Monitoring Network Activities Physical Security.28 5 Introductions to DRP implementation DRP Implementation Design Design Description Security Implementation.31 6 Results Investigation of BGP misconfiguration, attacks and security solutions DRP implementation Results..33 Conclusion 37 Reference..38 Appendix

5 1 Introduction 1.1 Motivation Border Gateway Protocol (BGP) is highly vulnerable to number of attacks. BGP messages can be spoofed and tampered with resulting in the advertisement of false routing information to other BGP peers. Misconfiguration from one BGP peer on the internet can disrupt Internet routing. There are two main problems currently facing service providers in internet routing: firstly how to prevent BGP from being attacked, and secondly how to handle misconfiguration and define routing policy for BGP peering and transit networks. Routing updates are done dynamically and service providers do not have such tools to check routing updates before the BGP table is disrupted due to misconfiguration. Most of the checks involve manually debugging of all routing updates. BGP peers advertise routing information such as lists of network prefixes, AS path and other path attribute information. All routing information is sent unsecured and without any authentication and authorization. There are greater chances of attacks on BGP routing information. One can consider firstly how to provide better security for BGP messages to prevent attacks from happening that can result in the injection of bogus and false updates into BGP domain and secondly how to stop BGP peer to advertise false updates. 1.2 Goals The goal of this thesis is answer to following questions: How misconfiguration occurs in BGP and what causes misconfiguration How the impact of misconfiguration can be reduced What kinds of attacks are possible on BGP What the impact is of these potential attacks How to mitigate the BGP attacks and minimize risks without major changes in BGP design 5

6 How to demonstrate implementation of security solutions in complex BGP transit networks 1.3 Method This paper proposes defensive routing policy to prevent BGP from sustaining misconfiguration and protect BGP from malicious attacks. The first part is investigation of BGP attacks and misconfiguration in complex peering and transit environments. The second part includes demonstration of own BGP security solution in practical environment. The configuration of BGP in peering and transit networks is a very complex procedure and requires in-depth knowledge of policy-based routing. Defensive routing policy (DRP) is operationally deployable and does not require any change in BGP protocol design. Defensive routing policy combines the best security features of BGP and provides proper guidelines to configure BGP in a secure way. We will use Cisco routers and switches to implement DRP in practical environment. At present most of the internet operators and Internet Service Providers (ISPs) are using Cisco devices at the core, distribution and access layers in their domains. DRP implementation design has two routers in each ISP domain connected to Internet Exchange Point (IXP). Ingress and egress route filtering is used on edge routers to filter false and bogus updates that can cause spoofing attacks and prefix hijacking. Edge routers are also responsible for the authentication of EBGP neighbour. ISPs use SYSLOG servers to monitor all network activities whenever an attacker will try to send any malicious attack or update against defensive routing policy, edge router will take proper action against attacks and send log messages to SYSLOG server. At the end the results shows the effectiveness of DRP in real time scenarios for complex transit and peering networks. 1.4 Background The group of routers under common administration and sharing same routing policy is known as domain or Autonomous System (AS). Each AS has a unique 16 bit number assigned by internet routing registries [1]. AS number ranges are divided into two categories public ( ) and private ( ). Autonomous Systems (ASes) can be single-home or multi-home. Single-home ASes reach networks 6

7 outside their domain through a single exit point. Figure 1.1 shows connection between single home AS and service provider. Figure 1.1: Single home AS Multi-home ASes reach networks outside their domain thought multiple exit points. Figure 1.2 shows the connection of Multihome AS to different service providers. Multi-home AS can establish transit and non-transit relationship with another AS or ISP. In Transit relationships ASes allow to pass traffic of other ASes. In Non-transit relationship ASes do not behave as transit between ASes and block all traffic of other ASes. Figure 1.2: Multi-home AS 7

8 1.4.1 Border Gateway Protocol (BGP) BGP is an inter-domain routing protocol based on the path-vector routing method. The path is a list of ASes that a packet should follow to reach the destination network. BGP creates its own routing table for each route object. BGP table carries information about address prefixes and associated path list. The main purpose of BGP is to exchange network-reachability information and information about the list of autonomous system paths with other BGP peers [2, 3]. BGP is a highly scalable protocol used to manage large internet networks with big routing tables. BGP uses TCP at the transport layer to provide reliable communication. BGP is commonly used between internet service providers (ISP). There are two types of implementation of BGP. Internal Border Gateway Protocol (IBGP): BGP running inside same AS is known as interior border gateway routing protocol. External Border Gateway Protocol (EBGP): BGP running between different ASes is known as exterior border gateway routing protocol BGP Path Attributes Path attributes are basically a set of parameters that BGP uses to create routing policy and filtering. BGP path attributes are divided into four categories: -Well-known mandatory -Well-known discretionary -Optional transitive -Optional non transitive 8

9 Table 1.1 BGP Path Attributes Name AS-Path Origin Next-Hop Local-Preference Category Well known mandatory Well known mandatory Well known mandatory Well known discretionary Atomic-Aggregate Well known discretionary Community Aggregator Multi-Exit-Disc Optional Transitive Optional Transitive Optional Non-Transitive All BGP routers recognize well-known attributes. Well-known mandatory attributes must include in each BGP update messages and well known discretionary attribute may or may not be added into BGP update messages. It is not necessary that all BGP routers recognize optional attributes. Optional attributes may or may not be included in every update message. BGP routers may allow optional transitive attributes to pass through it but the BGP router does not allow optional non transitive attribute to pass other BGP router [4]. AS-path: As-path is a well-known mandatory attribute. The AS-Path is a list of ASes that a route passes through to reach the destination. A list of ASes is displayed in the AS path attribute. The route that has fewest AS numbers in its path list is selected as best route. AS-Path attribute also provides loop prevention for example if an AS number received its own AS number in the AS-path list that route will be dropped. 9

10 Origin: Origin is a well-known mandatory attribute. It defines the origin of the route information. Next-hop: A well-known attribute that defines the IP address of next border router. The next-hop IP address changes as the route passes through different ASes because for each AS next hop is different. The treatment of the next-hop attribute is different in the case of IBGP and EBGP [4]. Multi-Exit-Discriminator (MED): MED is an optional non-transitive attribute. The MED attribute is a value given to the routes when more than one entry point exists into AS. This attribute is used to select the best path for inbound traffic of AS. The path which has the lowest value of MED is preferred and the default value is 0. Local-Preference: Local-Preference is a well known discretionary attribute. It describes the IBGP peer s preference for an advertised route. Distribution of this attribute is local to AS. Atomic-Aggregate: Atomic-aggregate is a well-known discretionary attribute. The Atomic Aggregate attribute used to notify neighbour about routes those become invalid or dropped due to aggregation. Community: Community is an optional transitive attribute. The Community attribute is a 32 bit integer value used to group the number of destinations [1]. Each destination could be in more than one community. Tags are used to carry information about the routes within the AS or between ASes. This attribute is very handy for applying the routing policy as communities are grouped into various kinds according to their description of path attributes. There are some well-known communities like No Export, No Advertise and No Export Sub conferred. Aggregator: Aggregator is optional transitive attribute. It contains information about last AS and IP addresses of BGP peer that advertise aggregate route. 10

11 1.4.3 BGP Messages There are four types of messages exchanged between BGP to establish relationship and relaying of routing information. As BGP uses TCP for transportation at port 179, the common header of BGP messages consists of 16 byte marker, 2 byte lengths and 1 byte type which limit the message size to 19 bytes. The type fields define the message type. At the time of initialization the whole routing table is loaded and after that only incremental updates are exchanged. There are no periodical updates of the BGP states [2, 4]. The BGP messages are as follows: -Open Message -Update Messages -Notification Message -Keep Alive Message An open message is sent to start BGP session among BGP peers. This message is used to identify BGP peers by verifying Local AS number, local version and other optional attributes. BGP exchanges routing information with neighbour via the update message. The update message contains information about update prefixes and withdrawn prefixes. An established BGP session remains open for a limited time span to exchange routing information, if an error occurs during the usual communication of peers, the session will be terminate. Some errors are critical, which results in the termination of the BGP session immediately. The error warning is sent through the notification message. A hold timer starts as an update message which is received to ensure that some activity is in progress. If the hold timer expires, the BGP session will be non-operational. To keep the BGP session operational, a keepalive message is sent after every 60 seconds. If BGP peer does not receive any keepalive message it closes the session [4]. 11

12 2 BGP Misconfiguration and Attacks 2.1 Misconfiguration Misconfiguration can be defined as configuration errors that result in the unintentional advertisement of BGP routing information. Misconfiguration can occur in two ways either by slip or by mistake. Slip is defined as error in execution and mistake is referred as an error in which execution is according to plan. It is very difficult to clearly differentiate between slip and mistake [5]. Misconfiguration is also one major problem that can cause instability in internet routing. There are a number of examples of misconfiguration such as AS 2007 incidents in which AS 7007 accidentally advertised routes to the internet and disturbed internet routing for two hours. survey and Testing Connectivity are used to identify and verify the impacts of misconfiguration on BGP. survey is a very useful method to collect information from network operators about misconfiguration incidents. Connectivity problem causes a prefix to be unreachable due to misconfiguration. Testing connectivity is an effective way to verify that prefix is reachable or not [5]. There are two types of BGP misconfiguration. 1. Origin Misconfiguration 2. Export Misconfiguration Origin Misconfiguration In origin misconfiguration an AS accidentally inserts prefixes into global BGP tables. Origin misconfiguration incident is a set of prefixes instigated by identical ASes, whose route appearance and disappearance are restively close in space and time. First we need to know why origin misconfiguration occurs and how to avoid from misconfiguration. The following section describes the causes of origin misconfiguration [5]. 12

13 Initialization Bug: The configuration changes due to bugs in the router s software. The victim routers advertise more specific routes and then withdraw those routes after rebooting. Old configuration: It happens when operators made some changes in the configuration but have forgotten to place changes in a stable storage place with the consequence that the router reboots with old configuration. Sometimes the use of a backup-router without updated configuration can also be reason of origin misconfiguration. Redistribution: Redistribution is described as the learning of routes from other routing protocols. The operator specifies the technique by which the route is learned from other routing protocols. Misconfiguration in redistribution can cause advertisement of large numbers of faulty prefixes. Incorrect Summary: Due to incorrect summary of advertised prefixes, AS can announce smaller or larger prefix blocks than the original block.. Community: Communities are used to group the routes and shaping up the policy. If the wrong community is attached with the route, prefixes may not be advertised or announced. Hijack: When AS advertises the prefixes those are already assigned to other AS it is known as hijacking of prefix. Prefix hijacking can cause the prefix to be unreachable Export Misconfiguration When AS exports a route that violates AS own policy it is called export misconfiguration. An export misconfiguration incident is a set of paths with a bad sequence of ASes that might appear or disappear frequently from the BGP global table. An example of an export misconfiguration is when AS exports routing information from one provider to another provider and behaves as a transit AS between providers. Export misconfiguration occurs when AS-Path violates the commercial policy of ASes. To identify export misconfiguration, it is necessary to 13

14 know the relationship between ASes, but normally ASes keep their relationship secret from other ASes [5]. Figure 2.1 Cause of export misconfiguration: Prefix-based configuration is one of the biggest causes of export misconfiguration. Most of the time misconfigurations occur due to link failure. In Figure 2.1 customer C has linked with an ISP and ISP is linked with two major service providers, P1 and P2. The customer has also direct linked up with P1 used as a backup link. This network will work properly until link failure occurs between ISP and customer. The ISP selects a direct link to C to forward all traffic that is destined for the customer. In case of failure, ISP learns customer s routes from P1 and forwards this route to P2. Now ISP is behaving as a transit between P1 and P2 for all the traffic of customer C. This problem can be fixed by configuring a proper filter and appropriate route map. This mostly happens when a multi-homing customer has two links with different providers [5] Solution to Avoid Misconfiguration Numbers of methods are suggested to prevent misconfiguration such as new interface designs for users, high level language checkers and improved consistency of routing registries. All major issues of misconfiguration have been described above. To reduce the occurrence of misconfiguration, the administrative mistakes and 14

15 human errors should be checked. A new design for user interface is required to reduce the factor of human errors, which should be easy to use and understand [5]. After analyzing the causes of misconfiguration, it has become known that predefined rules are not followed during the configuration of routers. If operators follow a proper set of rules then the risk of human errors occurring will be reduced [6]. Incomplete knowledge of Router commands is also a cause of misconfiguration. To solve this problem Router Command Line Interface (CLI) needs to be redesigned. In this way origin misconfiguration factor can be reduced by up to 20 % due to the redesign of CLI. Router configuration is a low level detailed task. By using configuration tools operator can implement policy directly in high level language form to generate a low level configuration. A set of suggestions are available to use high level configuration specification and routing policy specification language (RPSL). The RPSL is used with internet routing registries and with different Network Management Systems (NMS). There are many vendors using their own set of functions for NMS, so it is almost impossible to have a unique universal NMS [7]. Another way to prevent misconfiguration in the BGP is by using a configuration checker. A configuration checker is a tool to reduce misconfiguration issues by comparing router configuration with its own configuration database. The configuration database of this tool must be updated and error-free [8]. Prevention of misconfiguration is also possible through making some extensions in the existing BGP protocol. These extensions are made in the BGP such as Secure Border Gateway Protocol (S-BGP). In S-BGP routing advertisement is authenticated and authorized to prevent improper announcement [9]. It avoids address space hijacking and foreign misconfiguration but self deaggregation is not handled by this extension. 2.2 BGP Attacks and Counter Measures BGP is highly vulnerable to attacks. These vulnerabilities can cause distribution of false routing information, session hijacking, prefix hijacking, network congestion and traffic delay. As the internet grows the ratio of BGP attacks and risks is also increasing. 15

16 2.2.1 Objective of Attacker In case of BGP the main objectives of an attacker are: -Black holing -Redirection -Subversion -Instability Black holing occurs when a network prefix is unreachable for larger portion of the internet. False route advertisement can be a cause of the black holing. The primary purpose of attacker is to attract traffic and then drop it on a particular router. Redirection occurs when path for network traffic to desire destination is forced to take a new path. One objective of redirection is to receive confidential information on destination network and the second is to send large amount of traffic to particular destination. Network congestion and redirection of excessive traffic for a certain link are the consequences of the attack as well. In subversion an attacker can modify the redirected traffic and then send to victim router. Attackers can send large numbers of advertisements that can cause slow convergence and instability in BGP routing [10] BGP Attacks There are number of ways to attack a BGP. Communication between BGP peers is a clear text communication. The attacker can send bogus BGP messages to BGP peers that can cause session termination. Normally the relationship between BGP peers is considered confidential and secret. Man in the Middle Attack: Man in the middle requires direct access to physical infrastructure to initiate attacks. Man in the middle can spoof all messages between BGP peers. The Attacker can insert new messages that can cause distribution of bogus routing information. The Attacker can also delete and modify messages. BGP send periodically keepalive messages to its neighbours. Deletion of keepalive messages by attacker can drop the session between peers. For example peer A and 16

17 peer B want to established BGP session. Peer A sends an open message to B and its state changes into open-sent state. When B receives an open message from A, it also sends open message to A. Upon completion of the message exchange, both peers are in the established state. At this point if the attacker sends an open message to any BGP peer, the session will be closed. This kind of attack is also called session hijacking [11]. Prefix Hijack and Sub-Prefix Hijack: BGP uses update message to send information about new prefixes and withdrawn prefixes. If the BGP peer advertises prefix that does not belong to it, but BGP peer pretends to be originator of that prefix is known as prefix hijacking. Other BGP peers receive hijacked-prefixes and send all traffic that is destined for those prefixes to the advertised peer. The victim peer does not receive any traffic about hijacked prefixes. The peer who advertised the hijacked prefixes drops all traffic that destined for those prefixes because those prefixes do not exist. Another way to distribute false routing information is sub prefix hijacking. This method is worse than prefix hijacking because it is difficult to identify the source of hijacked prefixes. Deaggregation and improper summarization are main causes of sub prefix hijacking [12]. Path Attribute Manipulation: BGP update messages also contain information about path attribute. Its means that malicious BGP peers can also modify path attributes of routes before forwarding to other BGP peers. The alteration in path can cause routing delay and congestion [11]. Multi Origin AS: Advertisement of single prefix by multiple ASes is known as Multiple Origin AS (MOAS). The occurrences of MOAS are very common on the internet. The MOAS incidence is an assurance that fake advertisements frequently happen on internet. A prefix originated simultaneously by more than one AS can create conflicts in BGP routing decisions [10]. Prefix Deaggregation: BGP uses longer subnet mask match mechanism for prefixes in the routing table. Suppose if peer A advertises prefixes /24 and /25. If the data packet comes for network , the router will choose the prefix with the longest subnet mask /25 for routing purposes. 17

18 In prefix de-aggregation the attacker splits the address block into number of more specific prefixes. The de-aggregation causes the advertisement of fake routes on the internet which are preferred due to more specific routes. A compromised BGP speaker can use prefix de-aggregation to create a black hole for a victim network. Prefix Deaggregation mostly occurs due to origin misconfiguration [10]. Route Flapping: The frequent appearance and disappearance of routes in the routing table causes route flapping. Route flapping creates delay in route processing and convergence [11]. TCP-RST and SYN Flood Attack: BGP uses TCP port 179 to the established session with other BGP peers. TCP is subjected to many forms of attack, such as TCP-RST and SYN-Flood attack. TCP-RST attack is used to reset TCP session with remote peer. The Attacker can send TCP reset request to reestablished TCP session. TCP is highly vulnerable to SYN-Flood attack. The Attacker sends only SYN messages to BGP peer but it never sends any acknowledgement to the BGP peer. BGP peer runs out of buffer memory and none of them are able to complete the TCP handshake [11] Counter Measures Initially, BGP version 4 did not have any security features. However later new security features were added to avoid the problem of misconfiguration and to mitigate attacks. Most of the attacks that were discussed above require successful spoofing. Successful spoofing is possible if the attacker has direct physical access to the link between BGP peers. Mostly BGP peers are connected through the layer 2 link. This is common perception that BGP is easy to spoof. To achieve successful spoofing the attacker needs to spoof a source IP address, source port and TCP sequence number. These three attributes must exactly match with victim devices to initiate successful attacks. TCP MD5 Authentication: In some cases attacker does not need to have access to physical links. For example TCP-RST attack, to mitigate this attack BGP uses MD5 signature option. TCP MD5 signature defines a new TCP option for carrying an MD5 18

19 [RFC1321] digest in TCP segments that helps to stop unauthorized access. Implementation of an MD5 signature option requires manually configured shared secret key on each BGP peer. If the attacker can obtain access to physical infrastructure, he still needs to have an MD5 key for authentication [11]. IPsec Over BGP: There are many proposals about implementation of IPsec over BGP. IPsec over BGP provides peer authentication, message confidentiality and message integrity. IPSec is a security framework for many security parameters. Implementation of IPsec over BGP is not possible in operational environments due to encryption processing load and key management. GTSM (Generalized TTL Security Mechanism): GTSM provides security against remote attacks and CPU utilization attacks. Routers using GTSM set time to live (TTL) value to its maximum 255. During this process BGP peers accept packet that have TTL value 254 or 255 [13]. Route Filtering: Route filtering prevents BGP from sending and receiving false routing updates to other BGP peers. Egress-filtering filters outgoing updates that give flexibility to announce desired prefixes to other peers. Ingress filtering is used to filter incoming updates. BGP prefix filtering is documented in DUSA. These addresses include special use prefixes and Bogon prefixes. The BGP peer also checks the origin of incoming prefixes that help to prevent prefix hijacking in the BGP. The owner of address block is verified from Internet Routing Registries (IRR). The database of BGP peer and IRR must be synchronized and consistent with each other to validate the association of AS with prefixes [14]. 19

20 3 Evaluate BGP Security Protocols In previous chapters we have discussed how BGP works, misconfigurations, threat models of BGP and counter measures for BGP attacks. In the internet infrastructure, BGP is a critical component which makes it possible to distribute information between different ASes and propagate routing information to ISPs. Vulnerabilities in BGP and malicious BGP speakers can impact on the exchange of routing information, this can create problems with delivery of routing information, network congestion and packets delay. That is why BGP security was covered in many research projects which have introduced new solutions with protocols and architectures. There are number of security approaches proposed by researchers but we will analyze some major approaches and architectures. The following section is a comparison of some proposed security solutions of BGP. These solutions are Secure BGP (S-BGP), Secure Origin BGP (SoBGP) and Pretty Secure BGP (PsBGP). We will analyze pros and cons of these security protocols. 3.1 Security Protocols In this section we will discuss three major security protocols. These security protocols work around two security parameters: Origin Authentication and Path Authentication. All these protocols provide Origin Authentication and Path Authentication using different security model structures and mechanisms S-BGP S-BGP is a comprehensive framework to secure BGP. There are four major elements of S-BGP such as Public Key Infrastructure (PKI), Address attestation (AA), Route attestation (RA) and IPsec. S-BGP uses two PKI. One PKI issues certificates to the organizations to bind prefixes with public key assigned to that organization. This certificate is used to prove ownership of prefixes. The second element is PKI that issues certificates to an organization to bind AS with routers that runs BGP. SBGP use Address attestation to provide origin authentication [15]. Address attestation is 20

21 used to verify the authorization of advertising block of prefixes. The owner of the address block assigns AA to a set of AS those are authorized to be advertised. Route attestation is a new optional transitive path attribute. RA has its own specific fields in BGP update message. RA is used to verify the integrity of an AS path. RA is digitally assigned by a BGP router to advertise routing updates. S-BGP use IPSec to provide message confidentiality, integrity and authentication. IPSec provide frameworks for different security protocols. Encapsulation security payload (ESP), Authentication Header (AH) and Internet Key Exchange (IKE) are main security protocols of IPSec. For confidentiality, IPSec uses the encryption algorithms data-encryption-standard (DES), 3DES, advanced encryption standard (AES) and rivest-shamir-adleman (RSA). For integrity IPSec uses the hashing algorithms MD5, Hash Based Message Authentication Code (HMAC) and secure hash Algorithm (SHA). S-BGP deals with four different types of data. Certificates, Certificate Revocation List (CRL), RA and AA. S-BGP does not propagate certificates, CRL or AA in update messages. Sending this information in updated messages can cause consumption of bandwidth and delay. S-BGP use repositories to propagate certificates, CRL and AA. Major ISP and internet exchange points use as repositories. Repositories periodically exchange their information with each other and forward to other ISPs. S-BGP distributes RA in BGP update messages as transitive path attributes. S-BGP routers receive information about RA and cache it into a local routing information base. All smaller ISPs connect to repositories to upload data such as certificates, CRL and AA. ISPs interact with RIR (routing information registry) to obtain certificates relating to prefixes and AS and upload all information to repositories for other ISPs [15] SoBGP SoBGP is an extension of an existing BGP to provide better security based on origin authentication. SoBGP adds new security messages with BGP messages to exchange security parameters. BGP peer signed security message with certificates are sent to other BGP peers. The receiver validates the certificate with its own public key certificates [16]. 21

22 SoBGP use three certificates to authenticate and authorize autonomous system. Entity certificate is a certificate that contains the autonomous number and the public key of the peer. This certificate is signed by any third party for example VeriSign. Authorization certificates bind autonomous systems to block prefixes that are allowed to be advertised. These certificates are signed by any upstream ISP or routing registries. Policy certificate describes the policy for the block of IP prefixes and connection between peers. This certificate is signed by the private key of autonomous systems [16] Pretty Secure BGP PsBGP makes use of two trust models: centralized and decentralized. The centralized trust model is used to authenticate AS numbers. The main idea is that all ASes must obtain public key certificates from some trusted certificate authority and AS number must be bound with own public key of AS. This trust model can provide authorization of AS number allocation and authentication with AS public keys. It can give guaranty that an attacker cannot be able to represent himself as another AS and make any decelerations. The decentralized model is used for verifying the property of IP prefix ownership. Main idea is that ASes must have a prefix assertion list. This list includes binding of an AS number and prefixes. One of the binding protocols is created for this specific AS and one for the other AS. If the prefix assertion list of peering ASes is consistent, the assertion is in order. This protocol lies between S- BGP and SoBGP. PsBGP use a centralized trust model for AS authentication and authorization. The Centralized authority (RIR) assigns a public key certificate to all PsBGP peers. PsBGP uses distributed trust model for verifying the IP prefix block ownership [17] Comparison of S-BGP, SoBGP and PsBGP Each protocol uses different approaches to provide security for BGP. There are many things that are similar in the architecture of these security protocols. 22

23 Table 4.1 Comparison of S-BGP, SoBGP and PsBGP Task S-BGP SoBGP PsBGP AS Number Centralized Decentralized Centralized Authentication Peer Authentication BGP peer BGP peer Certificate per AS Certificate Certificate Data integrity IPSec or TCP MD5 IPSec or TCP MD5 IPSec or TCP MD5 Origin verification Centralized Centralized Decentralized AS-path verification Integrity Plausibility Integrity Origin authentication PKI PKI Distributed PALs Security High High Medium Overhead High Low High S-BGP and PsBGP use centralized models for AS number authentication but SoBGP is different from others using a decentralized web of trust model. S-BGP and SoBGP use PKI and distribute certificates to each peer but PsBGP use only one common key to authenticate BGP peers. S-BGP, PsBGP and SoBGP support both TCP MD5 signature-based authentication and IPSec. These protocols also support dynamically maintenance of the MD5 authentication key. S-BGP and SoBGP use centralized mechanisms to authorize IP Prefix allocation that guarantees perfect security against hijacking prefix attacks. SoBGP does not provide strong as-path validation as compared to S-BGP and PsBGP. Overall S-BGP and SoBGP provide more security than PsBGP. The overheads of S-BGP and PsBGP are too high compare to SoBGP. Finally, none of them is still operationally deployable [17, 18] Deployment Issue of BGP Security Protocols S-BGP was proposed in 1997 by Kent but due to operational factors it has not been possible to implement SBGP on the internet. After S-BGP there are many proposals such as PsBGP, SoBGP, Secure Path Vector (SPV), inter domain route validation 23

24 (IRV) and other security solutions which have been proposed but none of them have been adopted so far due to either higher cost or complexity. There are some operational factors those create complexity to deploy these protocols. S-BGP involves high computational cost, expensive space cost and the difficulty of establishing centralized PKI. SoBGP key format and signature types have not been decided upon. The PsBGP model does not go with the standard practice in the real world. These security protocols require hardware change, because current devices cannot support processing of these security protocols. ISPs and organizations are unwilling to change their current infrastructure. To deploy any BGP security protocol, new security design should be compatible with the current BGP. All security protocols have different path attributes that the current BGP cannot understand. Consequently it is not possible to deploy any new security protocol with the current operation of BGP [18]. 24

25 4 Defensive Routing Policy Today s internet infrastructure is complex and unreliable. Misconfiguration and attacks can cause unreliable communication between internet service providers (ISPs). We propose a security solution that comes in the form of defensive routing policy (DRP) for BGP because all ISPs use BGP to communicate each others. Implementation of DRP prevents BGP from intentional or non-intentional misconfigurations and malicious attacks. The DRP combines peer authentication, route filtering, managing customers and neighbours, logging network activities, physical security and guidelines to configure BGP in a secure way. These security features provide high level security in implementation of BGP. Implementation of DRP in an industrial environment can reduce the risk of session hijacking, prefix hijacking, sub- prefix hijacking, malicious route injection and misconfiguration. 4.1 Peer Authentication BGP peers authenticate their neighbours before establishing neighbour relationship. The MD5 authentication key is used to authenticate the BGP peer. The MD5 generates fixed length hash values using 128-bit key and attaches them to the TCP segment. BGP peers compute MD5 hash values and attach them to each message. The receiving peer will generate hash values using the same key and compare them with the receiving hash. If the values do not match, or the MD5 checksum is missing, the message will be discarded [14]. Peer authentication prevents BGP from unauthorized BGP peer to established relationship. 4.2 Managing Customers and Neighbours DRP defines guidelines to configure and manage customers and BGP neighbours. Firstly we need to define routing policy for customers and neighbours. For example Single-home customers do not need to configure BGP for routing. Single-home customers have only one exit point, they only need to configure default route to send traffic to ISP. Multi-home customers can advertise only locally assigned prefixes. Ingress filtering must be configured on edge routers to receive only locally assigned 25

26 network prefixes from multi-home customers. Maximum prefix limits features that define the maximum limit of route announcement by customers and BGP neighbours. Loopback interfaces should be used as a source for prefix advertisement to both IBGP and EBGP neighbours. BGP routes should not be redistributed to any internal gateway protocol (IGP) domain because normally IGP protocols are not capable to process a large number of routes. IBGP should be used between neighbours inside the AS. A list of prefixes should be defined that can be received from other neighbours, denying access to all other prefixes other than those in the list. Port 179 should always be used to make BGP sessions with BGP neighbours. The instability of routes is not desirable. Route flap dampening should be configured to limit the propagation of unstable routes [19]. 4.3 Route Filtering The major element of DRP is route filtering. Route filtering allows BGP routers to control and advertise correct routing information. There are two types of filtering: ingress filtering and egress filtering. Ingress filtering filter routes that are received from another AS and egress filtering is a filter router that advertises routes to other ASes. Filtering should be configured for individual customers and also for EBGP neighbours of other ASes or ISPs. Filtering should be based on prefixes, AS number and path attributes. There are four ways to implement route filtering: Prefix-List, Distributed List, Filter List and Route-Map. These features have different precedence orders for inbound filtering and outbound filtering [20]. For Inbound Filtering Prefix list > distributed list > filter list > route map. For Outbound Filtering Filter list >prefix list>distributed list>route map. 26

27 4.3.1 Filtering Recommendation Special Use Addresses Filter these prefixes because these prefixes are not allowed to propagate on public internet. 1. Private address range: RFC 1918 IANA reserved these addresses for local area network (LAN) purpose [21]. These addresses are /8, /12, / Multicast addresses /4: Multicast addresses of this address range are not allowed to travel on internet. 3. Experimental addresses /4: These addresses are reserved for research and experiments. 4. Loopback Address /8: This range is used for network self testing. 5. Link Local Network Address /16: These addresses are reserved for auto-configuration of network interface. Host on the network obtains an IP address from this range by auto-configuration if DHCP server does not respond to client requests. 6. Test-Net addresses /24: These addresses are reserved for documentation and example code. 7. Next Default addresses /24: These addresses are used to identify a new workstation temporarily during the boot process. 8. Bench Mark Working Group (BMWG) addresses /15: These addresses are used in benchmark testing for network devices. Over-Specific Routes Do not allow the advertisement or receipt of prefixes with /0, /1, /2, /3, /4, /5, /6, /7, /29, /30, /31, and /32 mask. 27

28 Bogon Addresses Bogon addresses are unallocated addresses which have not been assigned yet to any routing registry or ISP. Bogon addresses do not remain Bogon. IANA and other Routing Information Registries (RIR) assign these addresses to other ISPs and organizations with the passage of time. All ISPs filter Bogon addresses but updating of Bogon address list is required otherwise allocated prefixes will be blocked by old prefix or filter list. [22, 23] Own Address Space Do not allow the receipt of any update about own prefixes coming from the other BGP peers and customers. Filter update that contains information about your own network. This can cause prefix hijacking and spoofing attack. 4.4 Monitoring Network Activities Use SYSLOG Servers to monitor all traffic passing through the network. BGP updates should be monitored, updates permitted and blocked by the router. Monitoring helps to detect attacks and malicious traffic. After monitoring traffic, it is possible to take proper action against attacks. Monitoring should be configured for all updates which are advertised by the router or received from another BGP neighbour and customer. Monitoring can also reduce the risk of misconfigurations. 4.5 Physical Security Routing protocol security depends on physical security. All Routing devices must be secure in a locked server room and only authorized members have permission to access devices. As discussed above most of the attacks are possible if the attacker has physical access to network internal infrastructure. That is why physical links between BGP peer and customer must be secure. Power management is also part of physical security. Interruption in power supply can cause rebooting of the router and withdrawal of all routes. 28

29 5 Introductions to DRP Implementation This section demonstrates how to implement defensive routing policy and how to secure BGP protocols from attacks and misconfiguration. ISPs can be connected in two ways. Either they can have private peering or alternatively are connected via Internet Exchange Point (IXP). In this implementation all ISPs are connected through internet exchange points. An Internet exchange point is basically switching infrastructure that allows different service providers to exchange their traffic. ISPs use BGP routing protocol to facilitate peering with other ISPs. IXP use different switching technologies such as Fibre Distributed Data Interface (FDDI), Ethernet and ATM. The second way to connect ISPs is a private peering. Private peering can be achieved through dedicated TI, T3, E1 and E3 lines. Some ISPs use both peering; the purpose of using both peering between two ISPs is to have a backup link. If one connection fails so ISPs do not lose their connectivity and establish the connection through the backup link. Some major ISPs use both private peering and peering through IXP to provide better services to smaller ISPs and their customers. 29

30 5.1 DRP Implementation Design Figure 5.1 Interconnected ISPS through Internet Exchange Point (IXP) Figure 5.1 shows the working of ISPs in practical environment. This design shows different possible connections between ISPs and customers. 30

31 5.2 Design Description In this implementation all ISPs are connected to the internet exchange point. ISP1 and ISP2 also have private peering connected through dedicated lines. Both ISPs use dedicated lines as primary links and the link through exchange points as secondary links. All ISPs have two routers in their domain, R1 and R2 respectively. R1 uses EBGP to make peering with other ISPs and receive all traffic from the internet. R2 is responsible for filtering all malicious traffic, allowing good traffic and passing it on to other BGP neighbours. R1 is responsible for receiving all traffic from customers and advertising customer routes and traffic to other IBGP neighbours and the internet. ISPs can have two different types of customers: Single-home Customer and Multi-home Customer. In this design there is one multi-home customer that has two links with two different ISPs. Multi-home customers can use both links to send and receive traffic from both ISPs at the same time or use one ISP link as a primary link and another link as a secondary link. Multi-home customer is not allowed to behave as a transit between ISP1 and ISP2. It will forward only directly connected routes to ISP1 and ISP2. All loopback addresses simulate as single-home customers. Each customer is assigned to its 24 network prefix. The single-home customer can be a corporate customer or local ISPs. ISP1, ISP2 and ISP3 use AS numbers 100, 200, 300 respectively and multi-home customer using AS number. 5.3 Security Implementation This design demonstrates working of ISPs in a real time environment of complex peering and transit networks. ISP1, 2, 3 are major ISPs. These ISPs may be connected to local ISPs or different corporate customers. ISPs implement ingress and egress filtering for both customers and neighbours. We implement IP prefix list and filter-list to deny all inbound malicious traffic on both routers of each ISP. The template to configure inbound prefix filtering is given in the previous section (DRP). Router 1 of each ISP uses a distributed list to allow only advertisements of its own prefix range. Only prefixes that will match ingress and egress filtering criteria are allowed to propagate into the network. ISP1 and ISP2 will use filter-list and community attribute no export to stop Multi-home customer to advertise false 31

32 routing update. Before establishing neighbour relationship, BGP authenticates each BGP peer with TCP MD5 key. All ISPs authenticate their EBGP neighbours before creating sessions. We decide to use maximum prefix limit for each ISP of up to 1000 routes. It can be varied according to network requirements. ISPs cannot send more than 1000 updates to other ISPs. It helps to avoid routing tables to become overflow. SYSLOG server is used to monitor all activities on the network. It helps to detect network attacks, view blocked updates and troubleshoot problems. If any ISP tries to inject malicious routing update against filtering policy, edge router on each ISP will drop those updates and send a message to the SYSLOG server. 32

33 6 Results This project consists of two parts. The first part investigates BGP misconfiguration, attacks and security solutions. The second part is a demonstration of the authors own security solution in a practical environment. 6.1 Investigation of BGP misconfiguration, Attacks and Security Solutions Implementation of security in BGP is a complicated task. Whenever security is involved we have had to face complexity. There are many factors that cause problems for BGP performance and stability. In this paper we discussed about the type of misconfigurations, attacks and security solutions. The main causes which lead to major problems in performance and connectivity are change in origin, prefix hijacking, deaggregation, unallocated address route injection, unauthorized route injection, route flapping and message modification. We discussed existing solutions and new security protocols but implementation of these protocols is not possible to deploy in industrial networks. Security in BGP is more complex and difficult due to some operational factors. These operational factors are CPU utilization, bandwidth, overhead, cost, storage, operational requirement and lack of knowledge to implement complex security mechanisms. Introduction of PKI, sending and receiving certificates, validation and management of certificated make these protocols far less feasible in terms of practical deployment. These security protocols do not inter operate with the current version of BGP. The current version of BGP can not understand path attributes of new security protocols which is one of the major barriers in deployment of security protocols. 6.2 DRP Implementation Results At the end we carried out some test cases to check the effectiveness of defensive routing policy against attacks and misconfigurations. 33