Early Warning System for the Border Gateway Protocol

MEng Computer Science Final Year Project Report

Ahmed El-abiary

Supervised By Professor Mark Handley 6th May 2011

This report is submitted as part requirement for the MEng Degree in Computer Science at UCL. It is substantially the result of my own work except where explicitly indicated in the text. The report may be freely copied and distributed provided the source is explicitly acknowledged.

University College London, Department of Computer Science

1

Abstract
This projects aims at producing a feasible security solution for the Border Gateway Protocol (BGP), a protocol ran by ISPs that carries out the core routing decisions made on the Internet. BGP suers from security issues that are ultimately down to it lacking a means by which it can verify routing information exchanged over it. This has left a huge security gap within BGP that has been lled with a damaging group of attacks known as prex hijack attacks. These attacks can, in summary, give malicious ISPs access to data being routed over the Internet, to a target IP address, that they will otherwise have no access to. BGP's security issues have long been known and there has been a substantial amount of work aiming at plugging the gaps in its security, however, none of this work has actually ltered its way to real life deployment. Our approach was to build a system, independent of BGP's implementation layer, that will allow an ISP running an instance of it to detect attacks against its owned IP addresses. Using routing information

instances share with one another each instance will build a live map of the Internet and will monitor this map for attacks. In order to test our solution we have built a BGP simulator atop which our solution code was ran/simulated and analyzed. In the process of developing our solution we encountered issues that we resolved by implementing many interesting features such as a custom ooding protocol and a distributed key distribution mechanism. We have found that instances of our solution we were able to detect prex hijack attacks in there various forms quiet eectively by relying on routing information shared from only 20-40% of the ISPs within the Internet, hence our solution certainly does not rely on full scale deployment to provide its instances with good protection. We have also found that, if our solution was adopted by all the ISPs within the Internet, the cost of sharing information between its instances is manageable. We believe that we have produced a robust and eective solution that can be seamlessly deployed by ISPs.

Acknowledgments
Many thanks to my supervisor, Professor Mark Handley, who has provided me with a wealth of knowledge that i have found to be invaluable throughout the course of this project.

Contents

1 Introduction
1.1 1.2 1.3 1.4 Border Gateway Protocol Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
8 10 12 13

Prex Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Related Work
2.1 2.2 2.3 2.4 Secure BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Secure Origin BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prex Hijack Alert System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inter-domain Route Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14
14 15 16 17

3 Requirements and Analysis

3.1 3.2 3.3 3.4 BGP Threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Early Warning System Threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metrics for success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18
18 19 20 20

Requirements for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Simulator Design and Implementation

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Conguration File Topology Generator Simulation Server Simulation Client BGP Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
21 21 21 21 22 23 23 24

Early Warning System Simulation Evaluator Display

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Early Warning System Design and Implementation

5.1 5.2 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EWSD net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24
25 25

5.2.1 5.2.2 5.2.3 5.3

Congured Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Random Peers / RPR messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post peering communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26 26 27 27 27 28 28 28 29 29 29 30 30 30 30 31 31 31 31 32 32 32 32 32 32 33 33 33 33 33 33

Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.3.3 5.3.4 Reasons and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distance Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Link State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Path Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

Inter-daemon communication 5.4.1 5.4.2

Tree Based Flooding Vs Indiscriminate Flooding Message Loop Prevention

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5

Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 5.5.2 5.5.3 5.5.4 Building the certicate store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detecting and Propagating Conicts . . . . . . . . . . . . . . . . . . . . . . . . . .

Periodic Key Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6

Graph 5.6.1 5.6.2 5.6.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Path store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Triple store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Triple history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.7

Building the graph 5.7.1 5.7.2 5.7.3 5.7.4

Current Route Assertion Messages

CRA Messages Periodicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CRA Messages Time to live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accepting Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.8

Maintaining the graph 5.8.1 5.8.2 5.8.3

Triple and Path expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviving Triples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9

Perspective suppression 5.9.1 Overview

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9.2 5.9.3 5.9.4 5.9.5

TRIPLES NOT IN MAP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 34 35 35 35 35 35 35 35 37 37 37 38

CLOSEST ONLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOT SUBSET OF CLOSEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combining suppression modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.10 Daemon on Daemon Threat and Attack detection . . . . . . . . . . . . . . . . . . . . . . . 5.10.1 False Autonomous System representation . . . . . . . . . . . . . . . . . . . . . . .

5.10.2 Message tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10.3 Replay attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.10.4 Random peering attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10.5 Tampering with Path Vector Protocol overlay . . . . . . . . . . . . . . . . . . . . . 5.11 BGP Threat and Attack detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.11.1 Detecting prex hijack attacks

5.11.2 Detecting policy violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11.3 Third party threat detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Testing and Solution Analysis

6.1 6.2 6.3 6.4 Validating BGP Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validating solution behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38
38 39 39 40 40 44 45 46 49

Protection capabilities 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5

First party detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Third party detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EWSD Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cost and scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stopping Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Conclusion and Evaluation

7.1 7.2 7.3 How well does it work Future work Self evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50
50 51 51

8 Bibliography
6

52

Introduction

Security is one of the main concerns associated with technology, a dynamic technical world presses upon us an ever increasing need to make current and new technologies more secure. Secure technologies have an adequate degree of protection that can ensure their correct operation under external inuence and the ability to detect and deal with malicious attacks. Attacks against technologies can come in many

dierent forms, many of which aim to achieve the same goal, to alter the operation of the technology to the advantage of the attacker. The level of security that we can consider as adequate varies with the nature of the technology we are attempting to secure. Naturally there exists technologies that are more prone to attacks then others and there exists technologies that if successfully attacked can lead to devastating results, such technologies can be considered to be high value targets. The value of a target technology is also aected by many more factors, these factors include the type of data the technology stores, the purpose and application of the technology and the value of the systems that it interfaces with. Having briey described what can make a technology a high value target we now introduce the Border Gateway Protocol (BGP). BGP is a technology that resides at the backbone of the Internet and is charged with its core routing decisions. We can consider BGP by previously mentioned measures to be a very

high value target. Compromising BGP security and altering its operation can have very dangerous eects, a single compromised node running BGP can cause a global ux in the routing decisions made all over the Internet. This global change can be executed in a manner that will give the attacker access to data being routed on the Internet that they will otherwise have no access to . An attacker can achieve this by advertising false information that will cause data to be routed through him. In this project we consider such information to be attacks on the Border Gateway Protocol. Nodes that have been compromised, falsely congured or purposely advertising such information are considered to be the attackers. The victims of these attacks are considered to be the destinations whose reachability is aected by the advertisement of false information. This project aims at producing a robust system that will attempt to provide a means of security for BGP nodes. This system will aim to detect malicious routing information being circulated over BGP We aim to build a system that will be

and provide early warnings when such information is detected.

implemented independently of BGP, it will run as a layer on top of BGP that will allow it to gain enough global abstraction to view all the necessary information required to detect attacks. Nodes running this system will be able to detect and warn when an attacker attempts to victimize any of the destinations they are authoritative for.

1.1 Border Gateway Protocol

BGP is an inter-domain routing protocol, its purpose is to communicate reachability information for prexes designated for use over the Internet. We refer to nodes running BGP as Autonomous Systems(AS), an Autonomous System can be loosely translated to be an Internet Service Provider. Each AS is designated an Autonomous System Number(ASN) which uniquely identies it over the protocol. An AS is a collection of routers and IP networks, in order for an AS (A) to make its IP networks globally reachable, an arbitrary AS (B) that can physically reach AS (A) should be able to decide on what interface should data destined for these networks be forwarded on. ASes must be able to make these decisions

from any point within their domain. To achieve this goal ASes run both Inter-domain and Intra-domain routing protocols. Inter-domain routing protocols allow ASes to communicate with one another regarding routing information, whereas Intra-domain routing protocols allow an AS to internally propagate routing information learned from an Inter-domain routing protocol. BGP is the most widely used inter-domain protocol, it allows ASes to advertise to one another information regarding prexes that they can reach, this information is communicated using update messages[Figure 2]. Informally a BGP router sending an update message on behalf of an AS is telling the receiving BGP router the following:

If your AS sends me data destined for prexes within this messages [NLRI], it will reach its destination [Path Attributes] describes the route i use when routing to prexes within this messages [NLRI] I am no longer willing to route to prexes within this messages list of [Unfeasible Routes]

The BGP routers of an AS are typically its boundary routers that physically connect with other ASes. BGP sessions running between BGP routers from separate ASes are referred to as external BGP sessions (eBGP), whereas BGP sessions running between BGP routers from the same AS are referred to as internal BGP sessions (iBGP). The operation of eBGP and iBGP varies slightly. BGP routers will not forward routing information heard from one iBGP session onto another iBGP session. When a BGP session is bought up, both routers at each end of the session will transmit their whole routing table to one another in the form of Update messages. This information is then kept alive by each end periodically transmitting to the other end a keep alive signal. The BGP routers at each end of the session will send further update messages over the session when they learn new routes for prexes.

Attribute

Description

Inuence

LOCAL PREF

A numerical representation of how much the peer that a route was heard from preferred it. This attribute is ignored if the route was heard over eBGP

Select the route that has the highest LOCAL-PREF value. If multiple routes have equally high LOCAL-PREF values then consider the AS-PATH attribute Select the route that has the least amount of hops in its AS-PATH. If multiple routes have an equally low hop count for their AS-PATHs then consider the MED attribute BGP only considers the MED value if it is comparing routes heard from the same AS. If MED is considered BGP will choose the path with the lowest MED value. Paths that have not been selected as best routes due to the previous attributes will be inuenced by this attribute . BGP chooses a path learned through eBGP over a path learned over iBGP

AS PATH

A sequence of intermediate ASes between the peer a route was heard from and the origin of the route. Generally describes the path that will be traversed by packets if the route is chosen.

MED

This attribute is used when two ASes have multiple connection points, it is used by the advertiser of a route to inuence which of these connection points the receiver should use for routing i.e. (choose as its best route)

iBGP

Indicates whether this route was heard from the same AS through an iBGP session or heard from another AS through eBGP session.

[Table 1] BGP will process every prex within the NLRI of an update message it hears over a BGP session. To process a prex BGP will rst add the route described by this message to the list of routes known for that prex, then it will compare all of the routes within this list to one another and decide on which of these routes it should route on. The comparison between routes is based on their respective attributes, hence the route that has attributes better then all other routes is usually the one BGP will decide on. If this decision leads to a new route being selected then BGP will send update messages over its BGP sessions thereby informing its peers of this new route it has chosen/learned. [Table 1] shows the purpose of the main route attributes used within BGP's decision process, It also shows how they inuence BGP's decision on selecting between routes.

BGP also allows policy based routing, this means that an AS can decide on whether to forward reachability information heard from one AS to another AS. The most notable attribute used to aid policy based routing

is the COMMUNITY attribute which is an instrumental tool in enforcing policies. BGP routers generally class peers by one or more classiers that describe the nature of the peering. An arbitrary route received at a BGP router will be tagged with the class of the peer it was received from. BGP routers inturn will only re-advertise such routes to a certain class of peers [Figure 3]. A routes COMMUNITY attibute is used to store information about the class of the peer it was heard from, it is also sent as a path attribute of routes advertised to iBGP peers to ensure that they also apply routing policies correctly.

To consolidate our understanding of BGP i have put together a sample topology that should clearly demonstrate how BGP propagates reachability information that is used to route data. [Figure 4] shows the paths BGP routers within the topology acquire for a prex 25.0.0.0/8 that has been advertised from router (J) at AS(1023). [Figure 4] also points out critical route selection and policy based routing decisions made by BGP and how these decisions aected the paths each router learned for the prex 25.0.0.0/8.

1.2 Security issues

BGP is a vulnerable protocol, it's vulnerabilities stem from it's inability to verify routing information exchanged over it. valid. BGP routers generally consider routing information heard from a BGP peer to be

This implicit trust relationship between BGP peers is the seed from which most BGP security

issues have sprouted. BGP's trust model may be the product of a naive view of the Internet which perhaps was true at the time of its deployment. Such a view will hold that ISPs or ASes have no incentive to advertise false information over BGP. This view certainly does not apply in the Internet as it is today and there are many reasons as to why this this trust model is no longer a good t for BGP. For example:

10

As ASes become more topologically complex the probability of misconguring BGP routers increases, this can cause BGP routers to advertise incorrect routing information that constitute an attack on BGP.

ASes may be under the control of an agenda that motivates them to purposefully advertise false information. An agenda's motives behind such actions could be to gain access to sensitive data

destined for known prexes and/or black-hole this data.

How prex hijacking works?

Prex hijack attacks are a group of attacks that can be carried out on BGP. This project is mainly concerned with these attacks and hence we will describe how they work and what important factors we should consider when thinking about the eectiveness of these attacks.

This group of attacks aims at giving the attacker access to data destined for a prex. An attacker gains this access by advertising routes with attractive attributes that will cause other ASes to prefer routing through them over any other AS. One of the main attributes manipulated by the attacker to achieve this is the AS-PATH attribute. The attacker advertises a route for a prex with an AS-PATH attribute that aims at providing other ASes a shorter path to the target, this shorter route will see data destined for the target prex travel through the attacker. More sophisticated attacks will see the attacker factor in knowledge of the export/import policies of ASes into their attack. For example, the attacker might advertise a less attractive route knowing that strategically located ASes have an import policy of applying high LOCALPREF value to routes heard from him. We use the term strategically located AS to describe an AS that falls under one or more of the following categories :

An AS that

must be attracted to the attackers route in order for the attack to work more ASes will also attract to the attackers route. increases the probability of attracting more ASes
It then shows the eects of an attack by

An AS that if attracted guarantees An AS that if attracted

[Figure 5] shows an example of an attack on BGP. It shows the paths learned and chosen by ASes within a topology for a prex advertised by a router at AS(1023).

AS(8009) which makes one of its routers advertise an empty AS-PATH for the prex i.e. (claiming that it also owns the prex). We will discuss key points in this attack that generally apply to prex hijacking attacks.

11

1.

Knowing more information about the current routes held by an AS for a target prex makes the attacker more able to attract that AS to their advertised route. In this attack AS(8009) which is a
customer of AS(8000) knew that it will attract AS(8000) because providers prefer routes heard from customers AS(8009) over routes heard from providers AS(1023).

2.

Knowing the export policy of ASes makes the attacker capable of formulating an attack that can attract more ASes to their advertised route. In this attack AS(8009) knew that being a customer of
AS(8000) its routes if accepted will generally be forwarded onto all peers of AS(8000).

3.

Shorter AS-PATH's can be eective in attracting ASes local to the attacker. The further an AS is from an attacker the less likely they will be attracted to a shorter AS-PATH style attack. In this
attack AS(3210) saw a shorter path for the target prex; However, AS(1123) saw a longer path due to the intermediate ASes between it and the attacker AS(8009).

4.

Attacks can have a partitioning eect, where dierent subsets of ASes select routes that are destined for dierent sources. In this attack the topology has partitioned on the target prex.

1.3 Prex Hijacking

We briey discussed prex hijacking; However, our mention of prex hijacking was for introductory purposes and does not meet the level of understanding required for this project. In this section we would like to elaborate on the specic types of prex hijacking an attacker can mount, how the attacker can mount them and the prerequisites for the attack to be successful.

Valid prex attack is an attack on a prex where the attacker advertises a malicious route for a prex
that has been explicitly advertised by another AS.

Direct prex hijacking is a variant of a valid prex attack where the malicious route claims through its
AS-PATH attribute that the attacker is the origin (owner) of the target prex. To do this the attacker's advertised route will have an AS-PATH attribute with the rst hop as his ASN.

Indirect prex hijack is a variant of a valid prex attack where the malicious route preserves the target
prexe's real and valid origin. To do this the attacker's advertised route will have an AS-PATH attribute with the rst hop as the ASN of the known origin for the prex.

Invalid prex attack is an attack on a prex where the attacker advertises a malicious route for a prex
that has either been implicitly advertised by another AS or not advertised at-all.

12

Deaggregation prex hijack is a form of invalid prex attack where the advertised route is for a subprex of a valid prex being advertised by some AS. This attack is very eective because BGP implements longest prex match where it will use the most specic prex that the destination IP of a packet falls under to route to. Since this sub-prex has not been advertised by any other AS the attackers advertisement could be widely accepted by other ASes thereby making this attack very eective. e.g. AS(X) advertising 29.0.0.0/8, Attacker advertises 29.19.10.0/24

Aggregation prex hijack

is a form of invalid prex attack where the advertised route is for a prex

whose sub-prexes are being advertised by some ASes. As previously mentioned BGP implements longest prex match and hence this attack may seem redundant. However, if any sub-prexes of the attacked

prex being advertised by other ASes are withdrawn, the attacker will have access the the prex space of the withdrawn sub-prexes from all the ASes aected by their attack. e.g. AS(X) advertising 30.10.0.0/16, Attacker advertises 30.0.0.0/8

1.4 Problem Statement

Prex hijacking is the most prominent security issue with BGP, if used correctly this group of attacks could inict serious damages on a target prex. In response to this security issue several secure implementations of BGP have been developed that either partially or wholly protect against prex hijacking. However,

BGP has proved itself very hard to replace, even with its security issues there are very few if any ISPs who will dare to replace it. ISPs that intend on deploying a new version of BGP will need to reboot their BGP routers, these routers will then have to be monitored closely to ensure that they operate correctly under this new version of BGP and that they can deal with the huge sudden inux of routing information from their BGP peers upon reboot. This means that an ISP choosing to deploy a new version of BGP must opt for a slow incremental deployment strategy to avoid this huge transient load. This will come at a great cost for an ISP and will unlikely bring about any benets for that ISP until other ISPs follow suit and deploy the same version of BGP. The stubborn stance ISPs have taken against changing their deployed BGP version proved to be the crux of our solution's design. We could have opted for a solution that will attempt to

stop prex hijack attacks

at BGP's implementation layer i.e. a secure BGP implementation. Our solution would then most probably be added to the sizable list of similar solutions that aim at securing BGP but are in eect ignored by ISPs. To avoid this being the fate of our solution we opted for a design that will see our solution run as a layer on-top of BGP. This design will see an instance of our solution run on an AS and interface with one or more of its BGP routers using iBGP sessions. Through these interfaces our solution, on behalf of the AS it is running on, will attempt to

detect and warn

when hijack attacks against its AS's prexes

occur. Instances of our solution running on dierent ASes will be able to communicate through congured peerings with one another. Our solution instances will use these communication channels primarily to

inform one another of routing information they have seen over their own BGP interfaces. This is a crucial design choice in our solution that will allow us to bridge the partitioning eect of prex hijacks[Figure 7].

13

We anticipate that our design will provide an easy and inexpensive BGP security solution that detects and warns against prex hijacks. It is our hope that this project will produce a solution design that can be quickly and easily deployed by ISPs. This project aims at designing and implementing our abstractly described solution and simulating our implementation on-top of a BGP simulation that we also aim to implement. Using this constructed

simulation we aim to analyze the theoretical cost and eectiveness of our design, from our analysis we aim to make appropriate changes to our solution's design. Our changes will aim at minimizing our solution's running cost and increasing its eectiveness in detecting prex hijack attacks. We also aim to identify the advantages and disadvantages of the approach we took to solving this problem, more specically we would like to answer questions such as:

Can our solution stop prex hijack attacks or does our approach limit us to only being able to detect and warn against prex hijacking?

What level of security can we provide in comparison to solutions that embed themselves in BGP's implementation?

Related Work

There has been a substantial amount of work carried out aiming to provide a means of security for BGP. Some of this work has resulted in new secure BGP implementations and some has resulted in systems that attempt to provide BGP security independent of BGP's implementation layer. In this section we will make a mention of the most prominent of these solutions and how they protect against prex hijacking.

2.1 Secure BGP

Secure BGP (S-BGP) is a reimplementation of BGP that provides

verication .

origin authentication

and

path

Origin authentication allows S-BGP routers to verify that the originator of an update

message is authorized to advertise all the prexes within the messages NLRI. Path verication allows S-BGP routers to verify that the AS-PATH seen in an update message physically exists and every AS on the path has authorized it for use.

14

S-BGP achieves these two properties through the use of cryptographically signed update messages and through the use of trusted certicates. To verify an update message an S-BGP router requires the following:

Address Attestations(AA) for each organization that owns a prex within the messages NLRI. AA's
are used by organizations to authorize ASes to originate prexes they own. Route Attestations

(RA)

from every AS along the AS-PATH. RA's are used by S-BGP routers to

authorize neighboring ASes to advertise prexes, within an update message's NLRI, through the update messages AS-PATH.

Certicate's for every S-BGP router that was involved in the signing of RA's along the AS-PATH

With these resources S-BGP routers can verify that the origin and AS-PATH of an update message is valid. To verify this an S-BGP router must carry out the following steps on any received update message:

Verify that the owner of each prex within the messages NLRI has stated the origin of this update message within its AA

Verify that the update message contains an RA for every AS along the messages AS-PATH Verify the signature of each RA for each ASi within the AS-PATH {ASn , ..., ASorigin } Check that each RA for an ASi veries the sub AS-PATH { ASi , ..., ASorigin }, the NLRI and ASi+1

S-BGP's operation provides robust protection against prex hijacking and to a large extent eliminates BGP security issues. There remains residual cases where an attacker can replay RA's for a short amount of time after a route withdrawal. The notable issue with S-BGP is the high cost of cryptographically signing and verifying update messages. Implementations of S-BGP have been developed and tested; However, hardly any ISPs have actually adopted it. Even though S-BGP solves the problem it remains to much of a risky and expensive choice for ISPs.

2.2 Secure Origin BGP

Secure Origin BGP (soBGP) provides

origin authentication and validation of path existence.

Unlike

S-BGP, soBGP does not verify that an AS-PATH seen in an update message is actually validated for use by each AS on the path. soBGP provides a weaker form of route validation in that it only ensures that the AS-PATH physically exists. To oer this protection each AS must have the following resources stored in a trusted database.

Entity Certicate(EntityCert)

containing the public half of the ASes public/private key pair that authorizes the AS to advertise a set of prexes listed in

Authentication Certicate(AuthCert) AS Policy Certicate(ASPolicyCert)

the certicate, and delegate authority over prexes/sub-prexes to other ASes

signed by the AS containing a list of the ASes peers.

15

Using these resources each soBGP router builds a topology map of the inter AS connections. This map is used to verify that AS-PATHs seen within update messages physically exist i.e. they t within the map. To verify the origin of a prex there must be a chain of AuthCert delegations between the update's origin and the owner of the prex. soBGP will verify the origin of all prexes seen within the NLRI of the update message. soBGP's operation mitigates the threat of prex hijacking; However, as a product of soBGP only verifying route existence an attacker can still mount eective prex hijack attacks. An attacker can advertise an update message with an AS-PATH of a route that physically exists, but one or more hops within that route are invalid due to export policies. For example, the attacker advertises a route for a prex with the correct origin with the following ASPATH {ASattacker ,ASn ,ASorigin }. Physically this route exists; However, ASn will not usually advertise

routing information heard from the origin AS to the attackers AS. Although soBGP does not wholly solve prex hijacking, it severely limits an attackers options. soBGP's weaker security relative to S-BGP is a product of it giving up S-BGP's most expensive operations. Implementations of soBGP have been developed and tested; However, hardly any ISPs have adopted it. Even though soBGP oers a substantial increase in BGP security, changing BGP implementations remains to much of a risky choice for ISPs.

2.3 Prex Hijack Alert System

Prex Hijack Alert System (PHAS) is a system that aims at providing prex owners warnings when an attacker hijacks any of the prexes they own. monitors as its source of routing information. PHAS takes advantages of currently established route Route monitors typically have peering agreements with

hundreds of ASes that allow them to view real time BGP updates from many dierent perspectives. PHAS takes input from such monitors and uses this input to detect prex hijacks. As illustrated in [gure 8] PHAS is composed of several sub systems:

The

Origin Monitor
Origin Set.

processes real time data heard from BGP monitors. It maintains for each

registered prex a set of ASes originating it as revealed by the processed monitor data, this set is called the PHAS maintains an Origin Set for each prex registered by a user of the

system. Changes in the Origin Set of a registered prex trigger

Origin Event s.

16

The

Notication Transmitter processes Origin Events.

It decides on what events it should ac-

tually warn on, then sends a signed email notication to the client that registered the prex whose Origin Set has triggered this event.

The

Local Notication Filter

automatically processes received notication emails.

It veries

notications by checking their signatures. congured lter. criteria.

Veried notications are then passed through a client

Using this lter the client can choose to ignore notications that meet certain

The

User Registration system allows a prex owner to register a prex for monitoring.

The basic design of the system allows registered owners of prexes to receive slightly delayed warnings when one of their registered prexes are DIRECTLY hijacked. Proposed extensions to PHAS would allow the system to detect and inform registered prex owners of INDIRECT and DEAGGREGATION prex hijacks.

2.4 Inter-domain Route Validation

Inter-domain route validation (IRV) is a proposal for what is essentially a decentralized query system. Participating ASes deploy IRV servers that can authoritatively speak on their behalf. IRV servers can

query one another for static and dynamic information regarding the ASes they are authoritative for. Examples of such information are routing policies, import & export policies, communities policies, current peerings and BGP routing information. To provide Dynamic data it is proposed that IRV instances peer through iBGP sessions with BGP routers within the AS they represent. This gives them access to live BGP updates as seen by their AS's BGP routers. The concept of this solution is that by formulating queries to IRV instances, ASes can gather the necessary information needed to verify BGP updates. IRV gives its participants an option of how to use the query platform, for example, IRV servers can be congured to verifying all seen update messages or randomly seen update messages. Furthermore, IRV would give participating ASes the ability to control access to their static and dynamic data. IRV servers could, for example, be congured to only accept queries for a certain type of data from a certain subset of ASes. It is recommended that an IRV implementation should be secured by authenticating communication between ASes though digitally signed responses, or by authenticated transport such as IPsec/SSL/TLS. It is also proposed that IRV servers should gure out contact information of other IRV servers through a trusted database that stores and distributes authoritative IRV contact information. In summary IRV proposes the use of queries to implement features not currently present in BGP. Having presented an overview of IRV and what it tries to achieve, omitting many complex and detailed design choices, it is conceivable that an implementation of IRV could be widely deployed. However, IRV will

only be as eective as the information each AS is willing to publish, whether ASes would like to share any information at all regarding their routing policies is questionable.

17

Requirements and Analysis

3.1 BGP Threat model

To model the threat of BGP prex hijacking we chose to identify classes that describe the dierent behaviors and motivations of malicious ASes. We have identied four distinct classes that describe the nature of a malicious ASes behavior :

Interceptor

Describes ASes that choose to carry out any form of prex hijacking as previously described.

They do so with the intention of manipulating/black-holing data destined for the target prex. We assume these ASes do not try to preserve a route to the original owner of the target prex.

Attractor

Describes ASes that also choose to carry out any form of prex hijacking as previously described. However, they take on the role of the man in the middle such that they intend

to forward data they receive, destined for the target prex of their attack, to the prexes known owner. We assume these ASes carefully choose their attacks to preserve a route to the original owner of the target prex.

Erroneous

Describes the set of ASes that have one or more incorrectly congured BGP routers. These erroneous congurations of BGP routers causes them to announce information that amasses to an attack on BGP.

Colluder

Describes the set of ASes that advertise

any

information whatsoever over BGP with the

intention of increasing the eectiveness of another malicious ASes prex hijack attacks.

We have also identied several classes that describe the general motivation behind a malicious ASes behavior. Furthermore, we have identied, for each class, the associated behaviors that can be expected from ASes that fall under it.

Class
NOC Takeover

Description ASes that have lost control of their Network Operations Center(NOC) to an adversary. With this takeover the adversary has forcefully gained complete control of the AS, as such we expect ASes within this set to fall under any of the previously identied behavior classes

Behavior
Interceptor, Attractor, Erroneous, Colluder Interceptor, Attractor, Colluder

Agenda

ASes that intentionally mount or aid prex hijack attacks on BGP. These ASes are generally motivated by a Personal/Bussiness/Political agenda. As these ASes are intentionally mounting/aiding attacks we expect their behaviors to fall under most of the previously identied classes. However, we do not expect their behavior to be Erroneous as no AS will intentionally misconguring its infrastructure

Non Malicious Partial Takeover

ASes that have no motivation behind mounting an attack yet the have seemingly mounted one. These ASes are non malicious but miscongured ASes that have had some of their routers taken over by an adversary. With this takeover the adversary has complete control of

Erroneous

Erroneous, Interceptor

some of the AS's BGP routers

18

3.2 Early Warning System Threat model

Throughout this project we took great care in ensuring that our solution is itself secure against attacks. Considering that we have not yet divulged the inner workings of our solution we will present an abstract view of what we consider to be attacks on our solution and why we consider them to be so. Firstly we would like to introduce the term Early Warning System Daemon (EWSD) that refers to an instance of our solution running on some AS tasked with detecting prex hijack attacks against it. It is highly likely, that if our solution is widely adopted, some instances of our solution will behave maliciously to the advantage of a malicious AS. The threat model previously described for BGP entails that any solution that attempts to provide a means of security for it must also be secure. Assuming the dierent classes of attackers, it is possible and even highly likely that an attacker, knowing that our solution will detect his attacks, will attempt to disrupt its normal behavior. For example a

malicious AS might be running an EWSD, when it decides to mount a BGP attack it can attempt to disrupt the functionality of other EWSDs in order for its attacks to go undetected. Similarly an attacker that has managed to

takeover

an AS (partially or fully) could have control over any EWSD this AS is

running, and could again use it to try and make his attacks go undetected. Finally before we detail the actual threat model of our solution, consider that an EWSD can be specifically targeted by an attacker with a prex hijack attack in order to divert all information destined for that EWSD. With this in mind we summarize the threats a malicious/compromised EWSD poses to the operation of other EWSDs.

Advertising False Information

A malicious EWSD can advertise information that is not true to real life. We have mentioned that EWSDs use this an EWSD will periodically inform all other EWSDs of the current routes it can see. information heard from one another to detect attacks.

A malicious EWSD can then attempt to ood

false information over the EWSD net (described in section 5) that causes other EWSDs to detect false attacks and threats. This is a major concern since allowing false positives means that our solution will be unreliable.

Holding back critical information

A malicious EWSD can hold back information/messages that if seen by other EWSDs will cause them to trigger an alarm(detect attacks). Furthermore, a malicious EWSD might attempt to destabilize our solution by holding back other information necessary for its correct operation. This includes data such as the routing protocol overlay messages (RPO) and the public key exchange messages (PKE) (described in section 5).

Assuming Fake Identity

We had to establish a means by which each EWSD running on behalf of an AS can authoritatively identify itself and the data it sends to all other EWSDs. We achieved this by building a public key distribution system into our solution . Since there is no authoritative source (Public Key Infrastructure) by which

an EWSD can verify certicates they receive from one another, collisions could occur. For example, two

19

EWSDs (one of which is malicious) broadcast dierent certicates claiming to be authoritative for the same AS.

Re-advertising legit information

A malicious EWSD could store messages it has previously seen, and at a later point in time advertise these messages. We have found that the design of our solution rendered this not much of a threat, non the less we would like to protect against it.

Overloading Instances
Similar to a Denial of Service attack, a malicious EWSD could advertise huge amounts of messages over the EWSD net with the intent of overloading other EWSDs and bringing them oine. This concludes the summary of the threats that EWSDs could pose to one another. In (Section 5) when we elaborate on the security mechanisms implemented we will also elaborate on the specic attacks that they guard against and the adverse eects of not implementing them.

3.3 Metrics for success

Our design goals and thus the measures we will use to decide on how successful our solution is are as follows:

Eectiveness Cost Scalability Security

Maximizing the percentage of prex hijack attacks that can be detected by our solution. Minimizing the cost incurred by an AS deploying an instance of our solution. Ensuring that the growth in our solution's cost as more EWSDs are bought on-line is manageable. Ensuring that our solution is robust and secure, our solution should mitigate the threats against it described in the threat model.

Deployability Ensuring that our solution does not rely on external architectures for operation 3.4 Requirements for Simulation
As previously mentioned this project aims at building a simulation of our solution. Our aim is to build a BGP simulator rst and then layer our solution's code atop this simulator. We chose to build a simulation over an actual implementation because it seemed the more practical choice, using a simulator we are able to run our solution on large topologies. Without a simulator this will not be possible, we would have

needed access to many BGP routers over many ASes to actually evaluate our solution's eectiveness. Having mentioned why we chose to simulate our solution, our requirements for the simulator is as follows:

The simulation should be capable of simulating topologies of substantial size Both the BGP and EWSDs simulation should be as detailed as possible All design features of our solution should be implemented within the simulation The simulator should provide an interface for automated analysis of our solution's performance The simulator should provide an interface that allows the user to manipulate and view its state during simulations

20

Simulator Design and Implementation

4.1 Conguration File

This component, a le, is the main input of our simulator. It contains a description of the topology the simulator should initialize and simulate. We have dened our own syntax/language that allowed us to

intuitively describe topologies within this component. Furthermore, this le allows the user to dene attributes that control the simulator's behavior.

some

4.2 Topology Generator

The topology generator is a python script that automatically generates random topologies, it outputs the topologies it generates to the Conguration File in our dened syntax. This component takes as input certain conguration parameters dened in another conguration le, these parameters inuence the size, type and complexity of the topology that this script will generate.

4.3 Simulation Server

This simulation server as illustrated in [Figure 9] is in charge of loading,initializing and simulating a topology dened in the conguration le. This server provides an interface from which it can be accessed and commanded, this interface is a multi threaded TCP server that allows many clients to access the simulation and command it concurrently. Commands to the simulation server can be requests for information (graphical and textual) regarding the current state of the simulation or the topology model. A command can also be a request by one of the simulator's clients to perform live modications to the model being simulated. For example, a request to inject a route into one of the routers in the topology model.

4.4 Simulation Client

The simulation client accesses the simulation server through a TCP connection, over this connection a

21

client can query or modify the simulation running on the server. Our motivation behind this client server architecture was to allow us to view multiple concurrent views of the same simulation, thereby making our evaluation less dicult.

4.5 BGP Simulation

The BGP simulation, a main component of our simulator, is charged with running BGP over the simulator's initialized topology model [Figure 10]. It has been our aim to ensure that this component simulates real life BGP operation as close as possible. With this aim in mind we took the following actions in implementing our BGP simulator:

Designing the simulator to run at router granularity Supporting the simulation of both eBGP and iBGP sessions Supporting the conguration of BGP routers with MED and LOCAL-PREF lters Supporting policy based routing through the implementation of COMMUNITIES Implementation of route withdrawals, implicit replace and IGP metrics Implementation of route reectors

Our BGP simulator is cyclic i.e. it will continually cycle through each router within the topology model, on each visit of the router it will command the router object through an interface method to simulate its BGP implementation. A single cycle of OUR BGP implementation carries out the following actions:

Receiving and processing update messages queued at any of its router's BGP session queues Making appropriate changes as dictated by BGP operation to the routing table on process of a message.

Withdrawing any routes that have been withdrawn from the router. Sending newly learned routes over BGP sessions considering policy based routing and export lters.

22

4.6 Early Warning System Simulation

The EWSD simulator is charged with simulating instances of our solution (EWSDs) declared within the topology model. In this section we will elaborate on how EWSDs are simulated. As with the BGP simulator the EWSD simulator is cyclic, each EWSD runs when the router it is associated with is simulated. At each simulation of an EWSD, the EWSD will carry out the following steps:

Receiving and processing all messages queued at any of its Peer to Peer (P2P) session queues. Making appropriate changes to its internal storage structures as dictated by our solution's design. Scanning received messages for information that reveals BGP attacks and triggering alarms if such information is found.

Forwarding over its P2P sessions any messages received that resulted in the EWSD learning new information.

Checking its internal timer to see if a periodic event on the EWSD should be executed.

An EWSD running on a router, within the topology model in our simulator, is comprised of several components [Figure 11].

Controller Session Handler Graph Routing Protocol

Manages the overall operation of an EWSD. To simulate an EWSD the simulator will invoke this component. The Controller also interfaces with the BGP entity on the same router to view its routing table. Manages all the sessions that an EWSD has bought up. This includes sending and receiving messages and post peering communication. Stores a live map of the Internet, this map is built using information received from other EWSDs over P2P sessions and from the BGP table associated with the router the EWSD is running on. This component runs a modied routing protocol over an EWSD's P2P sessions. The performance reasons for this are later described.

4.7 Evaluator
The evaluator component of our system is in eect an automated client. This component automatically generates topologies using the topology generator, following which this component will invoke the simulation controller that will simulate this created topology. The evaluator can repeat this process many times,

23

at each invocation of the simulation controller i.e. at each new simulation, the evaluator injects data into the simulation and collects test specic data from the statistics component[Figure 9]. The evaluator component has multiple methods/tests that can be invoked by the user, each test evaluates a dierent aspect of our solution. Once a test has been completed by the evaluator its results are graphically displayed using a plotting library called matplotlib.

4.8 Display
To conclude this section we would like to briey discuss the type of interface we chose for our simulator. As previously discussed the simulation client is an interface from which a user can query/modify every aspect of a simulation. The client is a command line interface, the user can enter commands which are sent to the server and the replies to these commands are then displayed on the client terminal. The client can also send commands to the server asking it for a graphical representation of the simulation. The

server handles such commands by generating and sending back GraphViz formatted text that corresponds to the graphical view requested of it. The client expecting this text will compile it locally and display the resultant image. We found it absolutely critical to have some sort of graphical representation in this project. Graphical views allowed us to quickly verify that our BGP and solution implementations were working correctly. Examples of some of the graphical views that a client can request from the server are as follows:

The current topology model at AS and router granularity with an optional graphical route trace The graph currently held by an EWSD

Early Warning System Design and Implementation

Previously we have introduced this project, elaborated on our aims and goals and detailed how the simulator we have built for this project works. We now move on to this core section of our report, in this section we discuss in detail the design of our solution. We have mentioned that an EWSD running on an AS is tasked with detecting prex hijack attacks against that AS. We also described that an EWSD relies on information heard from other EWSDs to build a map of the Internet that it uses to detect these attacks. In this section we aim to provide a robust explanation of how EWSDs collaboratively work together to

24

achieve this functionality. We also discuss the design choices we have made, and furthermore how we have dealt with the security issues facing an EWSD as described in the threat model (Section 3.2).

5.1 Design overview

To give an overview of the design we are about to elaborate on, the following points describe the key design features of our solution

Each instance of our solution , an EWSD, is ran on a machine physically located at an AS An EWSD machine interfaces with one or more BGP routers on the AS it is running on. This allows an EWSD to view live BGP information from the perspective of its AS. We refer to this information as an EWSD's current perspective.

EWSDs inform one another of the ASes they are representing by advertising a certicate that binds their AS number (ASN) to a public key.

Inter EWSD communication is generally signed and coupled with an ASN. EWSDs receiving messages generally verify them using the certicate that corresponds to a message's ASN.

EWSDs periodically inform one another of their current perspective of the Internet as seen through their BGP interfaces.

Each EWSD merges all the dierent perspectives it has received into a single map of the Internet. EWSD monitor this map for any nodes/edges that reveal attacks.

In summary, our solution is a secure distributed graph builder that gives each of its instances a live birds eye view of routing information held by ASes. Unlike the IRV system (section 2.4) where its instances query one another for information needed to verify routes they have been seen over BGP, our solution aims at giving its instances(EWSDs) all the information they need to detect attacks against their represented AS. EWSDs will hold critical information, that they keep secret, about the AS they represent such as routing policies, peering relationships and import/export lters. Using this information an EWSD can

detect most forms of attacks against their represented AS. Our approach allows EWSDs to detect attacks without sharing this highly critical information. We believe that we have the advantage over a system such as IRV, where in order to maximize its eectiveness, its instances must share highly critical information.

5.2 EWSD net

We have coined the term EWSD net to describe the global system of interconnected instances of our solution(EWSDs)[Figure 13]. In (Section 4.6) we made a mention of the peer to peer sessions that are bought up between EWSDs. These sessions are communication channels between EWSDs. In this section we describe how these sessions are bought up and what design choices we have made that ensure that our EWSD net is a robust means of inter EWSD communication.

25

5.2.1 Congured Peers

When an EWSD is bought on-line by an AS it must be congured with a number of IP addresses of other EWSDs. This set of IP addresses would be congured into the EWSD by its administrator. How an administrator actually comes to know of these IP addresses is not within the scope of our project. However, we can envision that some sort of forum could be bought up to allow ASes to agree on bringing up these initial peering relationships. As mentioned, ASes must agree on these initial peerings (P2P sessions), our implementation necessitates that both ends of a P2P session are congured to accept session requests from one another (refer to the appendix , Daemon.py) We have chosen not to assume an authoritative source that can be queried by an EWSD for a set of IPs to peer with. We believe this would violate our deployability design goal as mentioned in (Section 3.3).

5.2.2 Random Peers / RPR messages

Once an EWSD establishes its initial P2P sessions it can seek to substantiate its presence within the EWSD net. To allow this functionality we have designed and implemented into our simulation a random peering mechanism. At the core of this mechanism lies the Random Peer Request (RPR) message, in

summary the random peering mechanism operates as follows:

EWSDs congure a FANOUT attribute that describes their desired number of P2P sessions. Periodically each EWSD will check if the number of P2P sessions they have established is below the FANOUT threshold.

If so an EWSD will create an RPR message, which includes a HOP COUNT attribute, and sends it to a random peer. This EWSD will also enter a state where they are willing to accept the next session request.

EWSDs that receive an RPR message with a HOP COUNT less then the 5 hops and are willing to accept this request (i.e. they have session capacity) will attempt to being up a P2P session the RPR's SOURCE_IP attribute as set by its originator

EWSDs that reject an RPR will randomly forward it with a decremented HOP COUNT, or dispose of it if its HOP COUNT is zero.

26

We have implemented this random mechanism in order to mitigate the threat of a coordinated attack against an EWSD. For example, if an EWSD is targeted by an attacker that attempts stop other EWSDs from sending it messages. With this mechanism an attacker does not know which EWSDs they must

compromise to block messages reaching his target.

5.2.3 Post peering communication

When a P2P session is established, certain information is communicated between the EWSDs at its ends. The P2P session will remain inactive until this information is exchanged

in order .

Ends send to one another their complete certicate store in the form of cached CRA messages (Section 5.5)

Each end adds its newly established P2P interface to the routing protocol overlay, this leads to a routing table swap via an RPO message (Section 5.3)

5.3 Routing Protocol

5.3.1 Reasons and Approach
Generally an EWSD's communication is intended to reach all other EWSDs within the EWSD net. However, the EWSD net does not form a complete graph i.e all instances within the net can directly communicate with one another. Our initial solution to this was to indiscriminately ood messages across the EWSD net. Each EWSD will send over

all

its P2P sessions any message they have received that they

have not seen before. With this solution an EWSD can be sessions it will reach all other EWSDs.

sure

that if it sends a message over all of its

However, it quickly became clear to us that this solution would be very expensive i.e. for every message sent over the EWSD net, each instance of our solution would receive duplicate messages on the order of the number of its currently establish P2P sessions. This simply seemed to expensive a solution and we sought to establish an alternative design. We wanted each instance of our solution to be able to identify which of its sessions are redundant. However, EWSDs had to make this decision collaboratively to ensure that the EWSD net does not partition. With this in mind we sought to implement a routing protocol that runs over P2P sessions. We quickly came up with a design that seemed to yield promising results.

Our solution is a path vector avored protocol.

EWSDs communicate new entries within their

routing table over their P2P sessions in the form of Routing Protocol Overlay (RPO) messages.

Our protocol maintains, for every entry, a path describing the intermediate EWSDs between the receiver of an RPO and the source of the entry i.e. it is a path vector protocol. However, our

protocol also maintains a metric value for each entry describing the accumulated cost of the entry's path.

27

Our protocol diers from the traditional path vector protocol in that it will choose, for each entry/source, the path with the lowest metric and not the shortest amount of hops.

Instances of our protocol on each EWSD assign exponentially distributed metrics to their P2P sessions

Once our protocol converges it identies P2P sessions that do not appear in its routing table. We consider these sessions as redundant.

Instances of our protocol will swap their complete routing tables over a newly established session after assigning a new metric to it.

The idea behind using exponentially distributed metrics is to place an increasing bias on each session, using this bias we attempt to identify redundant links within the EWSD net. Our metrics are exponentially distributed to ensure that a bias/metric set on a session can rarely be equaled by longer paths with smaller individual metrics. For example, a path with a single hop that had a bias of 100 can only be equaled by a path with 10 hops each with a bias value of 10. To summarize the operation of our protocol, if an EWSD assigns a high bias to a P2P session, this session will never be used unless it sits on the only path to some other EWSD [Figure 14].

5.3.2 Distance Vector

Our rst solution attempt saw us produce a distance vector avored protocol. Post implementation we realized that this design did not suite the dynamic nature of the EWSD net where P2P sessions could be frequently bought on-line/oine. This proved to be a huge problem, namely this presented us with the Count-To-Innity problem associated with Distance Vector Protocols. We attempted to rectify our implementation by including features that mitigate the eects of this problem such as SPLIT HORIZON. However, this bought about more complexity to our design and hence it was decided that we should rid of this implementation.

5.3.3 Link State

Our second attempt produced a link state avored protocol. We found it to be too costly and insecure as it revealed the entire EWSD net topology to what could be a malicious EWSD.

5.3.4 Path Vector

As we have previously described our nal solution saw us produce a path vector avored protocol. This solution eliminated the problems we found with our distance vector implementation. However, being a

28

path vector protocol , much like BGP , meant that each EWSD needs to keep all the paths it has seen for each entry/source. This is more expensive, but in the face of links failing/going oine we believe that we have made the correct choice. There are some security issues with this protocol. Firstly, we reveal to EWSDs some detail regarding

the EWSD net topology. Furthermore, a malicious EWSD could inject routes within the protocol in an attempt to eect another EWSD's reachability. Our implementation has addressed these security issues (Section 5.10.5)

5.4 Inter-daemon communication

5.4.1 Tree Based Flooding Vs Indiscriminate Flooding

Tree based ooding refers to the ooding mechanism that bases its operation on our previously described routing protocol. It diers from our previously described indiscriminate ooding mechanism in that an EWSD will only ood messages over sessions that our routing protocol has not agged as redundant. [Figure 15] shows the advantage of using tree based ooding over

well connected

EWSD nets of dierent

sizes. From this point onwards we assume that tree based ooding is the default mechanism used by an EWSD.

5.4.2 Message Loop Prevention

As our inter daemon communication is mostly ooded we had to devise a mechanism by which an EWSD can detect a message that they have previously received. Without such a mechanism messages would

innitely loop over the EWSD net. Our rst solution to this problem was for an EWSD to process all of its received messages, then only ood messages that caused a change in its internal state. We could be sure, through some intricate implementation details that we will not elaborate on, that two duplicate

29

messages would never cause a state change within an EWSD. We then realized that this approach was to expensive. On top of the expensive cryptographic verication of these redundant messages we would now have to process them, processing some messages such as the Current Route Assertion (CRA) message, later described, is an expensive task. As an alternative we implemented sequence numbers into our solution. An EWSD will reject a message, without processing it, that has a sequence number less or equal to the largest sequence number heard from the messages source (AS number). [Figure 16] shows that SEQNOs reduce the average processing load on an EWSD, within fairly dense EWSD nets, by approximately 20%.

Note :

Later, we mention how Peer Key Exchange (PKE) messages are cached by EWSDs and sent over

new P2P sessions. By only considering sequence numbers of valid messages, we can be sure that a PKE's sequence number will never be outdated. This is because, as we later describe, any message heard by an EWSD is invalid until a PKE/certicate is heard from its source.

5.5 Public Keys

For security reasons we require that every EWSD broadcast over the EWSD net a certicate that binds the ASN of its represented AS to a public key. The purpose of this is to allow EWSDs to send tamper proof messages across the EWSD net. The use of ooding necessitates that we provide this means of security, otherwise malicious EWSDs could tamper with any message that has been ooded through them. Sending tamper proof messages is absolutely critical to our solution behaving correctly. Some messages exchanged over the EWSD net, if tampered with, could render our solution ineective. We have chosen not to

assume an authoritative source that distributes these certicates since this will break our goal of making our solution easily deployable. distribution mechanism. As an alternative we have implemented into our solution a certicate

5.5.1 Building the certicate store

An EWSD exchanges both its personal certicate and all other certicates it has in its storage over any newly established P2P session, EWSDs that receive new certicates will store and ood them. We require that EWSDs swap their

whole

certicate store in case our solution is deployed in cliques. If so, then some

cliques could merge by a new P2P session coming online. EWSDs at the ends of this session must swap their whole key store to ensure that each clique knows about the others certicates. A certicate in our design and implementation is represented by a Peer Key Exchange (PKE) message. This message contains an ASN and the public key to bind to it. PKEs are signed with the private pair of their contained key, ensuring that certicates themselves are tamper proof.

5.5.2 Detecting and Propagating Conicts

When an EWSD sees a new certicate, attempting to bind a public key to an ASN that it already has binding for, it detects a conict. Conicting PKE messages are ooded by the EWSD that detects them, this allows a conict to be globally propagated across the EWSD net.

5.5.3 Periodic Key Change

For added security we have decided to implement a functionality by which EWSDs could periodically change the public key they have previously bound to their ASN. An EWSD does this by generating a new

30

key pair, then advertising a new certicate (PKE) that is signed with its old private key.

5.5.4 Verifying messages

All messages sent over the EWSD net are signed at the sender and veried at the receiver. To do this every message must contain the ASN of its sender. The receiver uses this attribute to lookup its certicate store for its associated public key. Following this look up, the signature of a message is veried and compared with the actual hash value of the message at the receiver. If the veried signature diers from the messages actual hash value, then the message is disposed of as it has been tampered with. Likewise, if no key exists in the store for the messages ASN then it is disposed of. For some messages, the signing and verication exclude some attributes that are allowed to change. For example, HOP COUNT for the RPR message. Our implementation uses hashing functions provided by python and an external RSA module to generate keys and verify/sign messages.

5.6 Graph
This component of an EWSD is a map of the Internet that EWSDs build collaboratively. In summary, an EWSD builds its graph by merging the dierent perspectives of the Internet heard over its P2P sessions. In this section will make a quick mention of the internal structures an EWSD uses to represent this map.

5.6.1 Path store

This structure was fairly static throughout our implementation. We needed a means by which an EWSD could map a prex to the set of AS-PATHs seen for it in all the dierent perspectives it has received. Furthermore, each AS-PATH, within this store, needed to be mapped to a dynamic expiry time.

5.6.2 Triple store

We needed a structure that an EWSD could quickly use to identify if an AS-PATH bore new information to its map. Our initial approach was to generate an undirected graph(adjacency list) from the

store ; However, we realized that we had made an erroneous assumption in assuming that AS peerings are
symmetric. With this realization we converted our algorithm to produce a directed adjacency list. This remained our approach for a short period until we realized that a directed graph eliminated crucial information from a map. Our directed graph could only be used to identify physical peerings as claimed by the AS-PATHs within the

path

path store ; However, it does not reveal any information that could be used

to detect if an AS is violating a routing policy. BGP facilitates policy based routing (Section 1.1). ASes could choose not to forward routes heard from a certain class of peerings over another certain class of peerings. With a directed graph all an EWSD could infer is that some AS-PATH claimed these links exist. It was nally decided that EWSDs should convert received AS-PATHs into triples. With triples an EWSD could begin to identify polices within its map. For example, if an EWSD's graph is provided with the

following path {1,2,3,4} and coverts it into the following triples (1,2,3) (2,3,4), the triple (2,3,4) informs us that some AS-PATH is claiming that AS(3) will announce to AS(2) a prex heard from AS(4). The

triple store

is a simple map, mapping a triple to a pair of values. The rst value is a reference count

indicating how many AS-PATHs with our

path store
31

reference this triple.

The second value is a trust

metric, the use of this value will be described in the following sections.

5.6.3 Triple history

As we elaborate on how our solution maintains the graphs at each of its instances (Section 5.8) we will mention that triples could expire. Expired triples are moved to the until they are revived or deleted.

triple history

where they will remain

5.7 Building the graph

5.7.1 Current Route Assertion Messages
Current Route Assertion (CRA) messages are the building blocks of the graphs at each instance of our solution. EWSDs ood/broadcast CRAs to inform on another of their current perspective of the Internet as seen through their BGP interfaces. This message contains, for every prex known by its originator, the list of AS-PATHs known for the prex. Flooding CRAs allows EWSDs to build the same identical graph i.e. they all have the same information from one another.

5.7.2 CRA Messages Periodicity

For our graph building algorithm we opted for a soft state design to greatly reduce the complexity of our solution. If we had opted for a hard state design, each EWSD would have to keep track of what it has ooded to its neighbors, furthermore, we would have needed a mechanism by which an EWSD can explicitly withdraw information they have previously announced in a CRA. This would have made our design much more complex and would have signicantly distracted us from the main goal of our solution. Our soft state design meant that each EWSD must periodically send its current perspective by ooding a new CRA. Likewise, EWSDs must periodically expire AS-PATHs, seen in a CRA message, that have not been renewed. Recall the expiry time attribute of AS-PATHs in the periodicity of CRAs is congurable (40 simulation cycles default). One could quickly realize that there would be a delay, relative to the periodicity of a CRA, between a BGP attack occurring and the EWSD that has a perspective that reveals the attack ooding a CRA. We have considered this, however, we believe that a possible delay in attack we were trying to

path store.

In our implementation the

stop

detection

is not as critical as if

attacks.

5.7.3 CRA Messages Time to live

CRA messages have a time to live (TTL) attribute that indicates to the receiver of a CRA message how long to keep the paths within it. By default the TTL attribute is always twice the periodicity of a CRA message, this means that when an EWSD expires a path that has not been renewed, it can be sure that the EWSD that announced it can no longer see it over its BGP interfaces. For example, EWSD(A) announces a CRA every hour with a TTL of two hours.

5.7.4 Accepting Routes

In our initial implementation EWSDs received from one another whole perspectives. We then introduced suppression mechanisms that aimed at reducing the cost (size) of CRAs. Without suppression an EWSD

32

would accept, into its graph, all information within a received perspective, EWSDs would also ood their whole perspective. With suppression, which is later describe, an EWSD would only ood and accept

necessary parts of a perspective.

5.8 Maintaining the graph

5.8.1 Triple and Path expiry
With the soft state design of our graph building mechanism, we needed a periodic method by which we could rid of expired state from our graph. Getting rid of state from our

path store

was trivial since each

path within the store had an expiry time. However, expiring triples that no longer exist in a EWSD's map was more dicult. Triples could be part of many paths and hence we had to implement a mechanism by which we can detect, for each triple, if any paths exist that still have a reference to it. Recall the reference count attribute for triples within the paths, within the

path store, exist that have a reference to it.

triple store.

A triples reference count attribute indicates how many If an expired path causes the reference count

of any triple within it to reach zero, this triple is move to the

triple history.

5.8.2 Building trust

The second attribute of a triple within the

triple store

is a trust metric, we use this metric to measure

how long we have seen a triple. In our solution's design our expiry check events are periodic, hence we use these events to build a triples trust. After an expiry check we increment the trust metric of all the triples that are still alive i.e. they still remain in the

triple store.

5.8.3 Reviving Triples

When we instantiate a triple into our map, due to processing a perspective, we rst consult the

history

. We instantiate the triple with the trust metric held for it within the

triple history

triple

(if any).

5.9 Perspective suppression

5.9.1 Overview
Suppressing information within a perspective is used to reduce the size of CRA messages by eliminating redundant information. Our graph building algorithm need only make EWSDs send parts of their perspective that would allow other EWSDs to detect attacks against their represented AS. All other information should be suppressed. With suppression an EWSD would pass their perspective through suppression lters and only broadcast, via a CRA, the parts of the perspective that have passed these lters. Likewise, an EWSD receiving a perspective will again pass it through suppression lters, accepting, into its map, parts of this perspective that have passed the lters. In this section we talk about the dierent types of suppression modes we have implemented, what information they eliminate and what types of attacks we can detect with them. Recall the dierent forms of prex hijack attacks that a malicious AS can mount (Section 1.3). Before we detail our suppression modes, we must rst make a clear distinction between suppression and re-suppression lters. Suppression lters are applied by an EWSD on parts of a perspective that are new

33

to its current map.

Re-suppression lters are applied by an EWSD on parts of a perspective that are

currently within its graph. Suppression lters process perspectives at prex granularity. perspective process every AS-PATH associated with it. For example, for every prex within a

5.9.2 TRIPLES NOT IN MAP

An AS-PATH will pass this mode's suppression lter if it contains at least one triple that is new to the graph of the EWSD applying the suppression. The re-suppression lter for this mode dictates that an AS-PATH must have at least one triple with a reference count of exactly one, such that if the this AS-PATH is allowed to expire, all EWSDs would loose a triple from their graph. This mode would allow EWSDs to build a graph that that they can use to capture any policy violation.

5.9.3 CLOSEST ONLY

If an AS-PATH (A), associated with some prex, has this modes suppression lter applied by an EWSD, the following is carried out.

Query the EWSD's

path store

for all the AS-PATHs currently held for the prex

Reduce the returned list to the set of AS-PATHs that have the same origin as (A) Identify the length of the shortest path out of this reduced list if A's length is less than or equal to this identied length, or A reveals a new origin/prex then A passes the suppression lter

Without going into detail of how we implemented the re-suppression lter, (A) would only pass this lter if no other AS-PATH has been introduced into the map that is closer than it and has the same origin. This mode was intended to allow EWSDs to build a graph that can be used to detect all DIRECT prex hijack attacks. In summary, this mode deterministically rids of all the AS-PATHs that do not reveal a new origin for a prex.

5.9.4 NOT SUBSET OF CLOSEST

This mode basically ensures that an AS-PATH (A), associated with some prex, would only pass if the following conditions hold:

(A) does not overlap with the closest path currently held for its associated prex. (A) must be compared with the closest paths that have the same origin as it

This mode was intended to allows EWSDs to build a graph that can be used to detect all INDIRECT prex hijack attacks. With this mode we rid of any AS-PATH that does not tell us of new peerings with the origin(s) of a prex.

34

5.9.5 Combining suppression modes

Suppression modes could be combined together, such that if a perspective passes any of the combined modes, it makes it into the CRA message to be ooded. From our analysis (Section 6) we have deduced that combining the suppression modes (TRIPLES NOT IN MAP & CLOSEST ONLY) gave the best trade-o between producing a graph from which we can detect most attacks and the cost of producing the graph.

5.10 Daemon on Daemon Threat and Attack detection

5.10.1 False Autonomous System representation
A malicious EWSD could advertise a certicate (PKE) attempting to bind an already bound AS number to a public key. Our solution could easily detect this attack as our certicate distribution mechanism

ensures that these conicts are globally propagated. In summary, If an EWSD receives a PKE message claiming to be originated by it, and a dierence exists between the EWSD's key and the key within the PKE, then this reveals a conict and a warning is raised. This warning presents the administrator with the IP address of the system that originated the attack.

5.10.2 Message tampering

EWSDs cannot tamper with messages being ooded. Changes to any restricted (non-changeable) attribute of a message would cause the message to fail the verication process.

5.10.3 Replay attacks

EWSDs reject all messages that have a sequence number less than or equal to the highest sequence number seen for the messages source AS. This guards against replay attacks.

5.10.4 Random peering attacks

The HOP COUNT state of a Random Peer Request (RPR) message is allowed to be changed whilst the message is being circulated over the EWSD net. To prevent an EWSD from abusing this by setting a high HOP COUNT value we have limited this attributes maximum value to 64 (6-Bits). A malicious EWSD could also attempt to block RPRs, however, since EWSDs send RPRs over random sessions, it is highly unlikely that a malicious EWSD can stop a signicant portion of RPRs. Finally, a malicious EWSD may also attempt to bring oine another EWSD by sending out many RPRs with his target's IP address within them. A malicious EWSD does this with the intention of overwhelming his target with session requests. As a solution to this we recommend that an EWSD machine be congured to drop requests when it sees to many.

5.10.5 Tampering with Path Vector Protocol overlay

Our path vector overlay as previously mentioned has allowed us to signicantly reduce the cost of ooding messages over the EWSD net. However, the use of this protocol bought to light signicant security issues that we had to address.

35

A malicious EWSD could advertise a path with a lower metric for the target EWSD's ASN. The attacker does this with the intent of making there targets neighbors identify their sessions to the target as redundant, hence bringing the target out of reach of ooded messages. Note that an attacker must manipulate the whole tree in order to make a target unreachable. The attacker must ensure that all EWSDs, most

importantly the targets neighbors, believe that the he is a cheaper route to the target, otherwise the manipulate tree will still include the target. Message signing/verication ensures that RPO messages are tamper proof and are originated by an EWSD, hence we have already limited the domain of attackers to live EWSDs. Prior to detailing the security mechanisms we have designed/implemented, recall that our protocol design dictates that paths with the lowest metric are chosen for each destination and that a path's metric is accumulated whilst being announced from one EWSD to another.

Inverse metrics
A crucial decision we have taken is for our protocol to dictate that EWSDs apply metrics on receipt of a path and not on its announcement/forwarding. This makes it impossible for an attacker to know if his attack will be successful. His neighboring EWSDs could receive his attack's path (RPO message) on high metric/bias sessions. Our protocol instance at any of these neighbors will not select the attackers path over the cheaper path it already holds. This increases the possibility of the target remaining within the tree, i.e. post attack, some neighbor of the target chose to retain its original path to it.

Reactive Hijack Protection (Proposed/Not Implemented)

If an EWSD, whose protocol instance has

converged, hears its own identity (originally its ASN) in an

announcement, it will withdraw its old identity and announce a new distinct identity. This mechanism ensures that no EWSD can ever be made unreachable. We relied on two two main factors when designing this mechanism, rstly we do not care about identities, we just want to identify redundant links. Secondly, if an EWSD has converged, it has waited a signicant period such that any of its previous announcement would have already looped. When analyzing our solution we found that this mechanism could be bypassed by an attacker. All the attacker needs to do is precede his announcement of a target EWSD's ASN with some redundant announcement that causes a global ux in the routing tables of our routing protocol. This will cause the convergence timer on his target to reset, his proceeding attack will then not be considered as one until his target's convergence timer counts down.

36

5.11 BGP Threat and Attack detection

5.11.1 Detecting prex hijack attacks
To detect prex hijack attacks an EWSD must be congured with the following lists :

Prexes Peers Atomicity

Prexes owned by its AS. Automatically detected via the EWSD's perspective. ASes that have peering relationships with the AS they are representing Non atomic prexes owned by its AS i.e. they are allowed to be deaggregated

Even though we can detect to some extent the list of peerings through an EWSD's perspective, it is possible that some ASes might not advertise would not see the peer in its perspective.

any

routes to one another.

This means that the EWSD

Direct Indirect Deaggregation

If a prex, within the local prexes list, is attached to an AS within the graph dierent from the EWSD's AS If the graph reveals any edge/peering between an EWSD's AS and an AS that does not appear in the EWSD's list of peers. If a deaggregation of a prex, within the local prexes list and not in the atomicity list, is attached to any AS within the graph.

5.11.2 Detecting policy violations

To detect policy violations an EWSD must be congured with the following information:

The routing policies of its AS The class of each peer within its list of peers

With this information an EWSD could trivially detect policy violations. When a new triple (A,B,C) is seen, such that B is the EWSD's represented ASN, the following steps are taken:

Identify the class of peerings held with A & C through the Check the identied classes against the secretly kept

peers class list

routing policies

Check that routing policies allow routes heard from class(C) peers be announced to class(A) peers

37

5.11.3 Third party threat detection

With the implementation of triple history we found that we could provide some degree of third party attack detection. To detect attacks against a prex our implementation and design rely on the following

The correct valid path for the prex has been advertised rst The attacker claiming a new path to the prex, advertises his attack some time later The attacker's path has lead to a new

triple appearing in or map

With these assumptions in mind, we implemented our third party detection mode in the following manner

An EWSD will inspect the path's of a prex it has heard a new path for (via CRA) For each of those paths, identify the lowest

history metric

(LHM) in its triples

Identify the two paths with the lowest/highest LHM If the lowest path's LHM is less than 50% of the highest path's LHM throw a warning

This means that some path, most probably the newly heard path, has some triple that is new/young to our map and hence has a very low history. We throw an Untrusted Route Warning because we already hold a live path whose component triples have been seen

signicantly longer over the EWSD's lifetime.

Testing and Solution Analysis

6.1 Validating BGP Simulation

In order to automate the validation of our BGP simulation we would have had to create a test suite that can inject routes within our simulation and ensure that that these routes have propagated correctly over the BGP objects within our implementation. Ironically, in order to create such a test suite we would be in-fact building another BGP simulator. If this is the case then any problem with our BGP implementation will persist within the test suite and hence will go undetected.

38

Our approach was to build within our client the ability to retrieve an array of data that can be used to manually conrm correct BGP operation. For example, retrieving the routing table of any router at any point within our simulation. We also added a feature by which the client can command the server to

return a graphical representation of the global topology at dierent layers of abstraction. The client can also graphically trace routes heard over BGP, for a certain prex, within these representations [Figure 12]. With both these tools we ran many simulations, injecting many dierent routes, verifying that the resultant route propagation over BGP was correct. Our injected routes tested every aspect of BGP's route selection algorithm which can be found in detail within our implementation (BGP.py). They also tested that our implementation's iBGP, eBGP and route reectors were operating correctly.

6.2 Validating solution behavior

In much the same manner as we validated our BGP simulation we also created commands that clients/we can use to ensure our simulation was operating correctly. Below is a list of these commands and what they were preliminarily used for

EWSD details, displays the currently detected threats by an EWSD within our simulation EWSD graph, a graphical display of the graph an EWSD within our simulation has built EWSD graph trace, a graphical display of the routes within an EWSD's map for a particular prex

Using these views we could verify that the overall behavior of our solution was correct. We consider correct behavior to be that all EWSDs build the same map and if an attack is injected within the simulation and the EWSD can detect it then it should. Thoroughly testing our solution proved to be signicantly more complex, at dierent points in time we had to add instrumentation code to ensure that every feature described in our solution design (Section 5) was operating correctly within our implementation.

6.3 Model
In this section we present the model that was used by our automated analyzer from which we have gathered the results revealed in the next section. Our aim was to model the current topology of the Internet as closely as our simulator permits. With this in mind we chose to make the ASes, within our automatically generated topologies, abide by the traditional multi-tier model.

Tier-1 Peer

with every other Tier-1 AS and is a

provider

of some Tier-2 ASes Tier-2 ASes could

Tier-2 Customers of Tier-1 ASes and providers of Tier-3 ASes. Tier-3 Customers
of Tier-2 ASes. Tier-3 ASes could

peer

with one another

peer

with one another

Our generator's output BGP topology also describes the classical BGP export policy described in [Figure 3] which is used in our actual simulation. Furthermore, in an attempt to capture some of the policies ASes

39

may deploy, we have chosen to make our generated topologies enforce through the use of LOCAL-PREF lters that an AS would prefer routes in the following manner:

Class
customers peers providers

LOCAL-PREF Reason
1000 500 100 Routes generate revenue Routes are free (conditional) Routes are expensive

We have also created two models to describe our solution deployment strategies. The rst model we call

non-seeded where EWSDs are deployed by random ASes and as such the growth of the EWSD net is random. The second model we call seeded where EWSDs are deployed in cliques and as such the EWSD
net grows radially around the rst deployed EWSD (the seed).

6.4 Protection capabilities

6.4.1 First party detection
We start our analysis with an overview of what kind of protection our solution oers. [Figures 18 & 19] show the global/combined protection against the dierent types of prex hijack attacks (Section 1.3) provided by our solution instances. We can see that our global protection grows linearly with the size of the EWSD net. As these gures reect attacks that can only be detected by an EWSD associated with an attacks target, their linear growth comes as expected and cannot be exceeded. However, what we did not expect was for this growth to persist with a seeded model. It was our intuition that an attack would be less likely detected in a seeded EWSD net. A seeded EWSD net grows radially around a single EWSD, hence we thought that attacks mounted from the extremities of the Internet might go undetected until the EWSD net grew substantially.

40

Our prediction was was true in the initial growth of the EWSD net [Figure 19]. However, after approximately 20% of ASes had deployed EWSDs, the EWSD net would have spread globally by traversing peerings and partially engulng Tier-1 ASes. This spread introduced perspectives to the net that allowed EWSDs to detect attacks from the extremities of the Internet. We can then assume that if the most

optimal non-seeded model and least optimal seeded-model generally follow linear growth, models therein should also follow linear growth. We consider our non-seeded model to be the most optimal because

random deployment maximizes the amount of distinct routes learned from dierent perspectives/EWSDs.

41

We would now like to perform some further analysis to discover how the growth of the EWSD net eects an EWSD's ability to detect attacks against its represented AS. [Figures 20-21] show that, with our default analysis model (Section 6.3), ASes running EWSDs have very good detection rates for all forms of prex hijack attacks. However, it turns out that the LOCAL-PREF lters in our analysis model completely

dominated BGP routing and hence attacks could attract much more ASes. This increased the probability that an attack would attract an AS running an EWSD leading to its detection. [Figures 21-22] shows the re-execution of our analysis but without our LOCAL-PREF lters. These gure show quiet clearly that, with default BGP operation, more EWSDs need be deployed to provide the same detection as our initial model. This shows that the eectiveness of an EWSD, its ability to detect attacks against its AS, is directly related to the routing policies of other ASes. These policies, which tend to be extremely complicated and kept secret, can increase/decrease our solution's eectiveness at lower deployment levels. However, no

matter what the policies are, as deployment tends towards 100% their eect on our solution's eectiveness becomes negligible. After thoroughly investigating the cause of the variance in the detection rate of attacks for ASes running EWSDs as displayed in [Figure 20-24], we concluded that these variations were simply down to the undetected attacks not being able to attract an AS running an EWSD. To conrm our conclusion we programmed our analyzer to keep track of the long run averages of attacks detected per tier whilst running our analysis [Figure 24 - 25]. Our results show that the variance in detection is generally not localized to any particular tier of ASes, but as we concluded it is distributed over dierent tiers. This is a main point within our analysis, it shows that there are no particular EWSDs that will experience bad protection because of their location/tier within the Internet.

With our modied model (no LOCAL-PREF lters) and a seeded EWSD net, it turns out that tier 1 ASes, as a whole, experienced a decreased average detection rate (approximately 85%). With some further analysis we found that, with no default LOCAL-PREF lters, attacks against tier 1 ASes were less likely to spread globally i.e. they make it past the tier 1 full mesh. Since a seeded model means that all EWSDs are clustered together, this further decreased the likeliness that attacks will reach an AS running an EWSD. However, we believe that our original model is a better description of the Internet as it is today. We have shown that our solution generally provides good rst party protection. Now we explore the ways be which an attacker can attempt to beat our solution. An attacker who wants to bypass our rst party

42

protection mechanism has two ways of attempting to do so, either through a malicious EWSD, or by mounting clever BGP attacks.

Malicious EWSD
EWSDs trust signed communication from one another, but what if one of the EWSDs is malicious? they can then authoritatively send messages with malicious payloads and all other EWSDs will trust their content. Our security mechanisms deal with this problem for most types of communications as mentioned in (Section 5.10). However, we have not addressed this problem with regards to CRA messages. The sender uses this message to inform all other EWSDs of his current perspective, but what if the sender broadcasts a malicious perspective i.e he may disclude attack revealing information and include information that reveals false attacks. This means that an attacker's CRA can easily trigger

negatives except if his AS is the only AS with an EWSD and a perspective that reveals the attack they
are trying to mask. An example of when an attacker can use this to his advantage is as follows:

false positives but can never cause false

The attacker's/colluder's EWSD advertises CRAs that show other ASes attacking its target prex The attacker then mounts his BGP attacks on the target prex The EWSD ran by the target prex's AS detects both the fake and real attacks, which of these is true?

This is quite a big problem with our solution, had we had this problem in mind whilst designing and implementing our solution then we could have implemented the following functionality to severely mitigate the eects of this threat. Recall that an EWSD monitors its built map for attack revealing information. What we have not mentioned is that the monitoring/scanning of a map is triggered by the receipt of an CRA/perspective i.e. a received CRA is used to modify an EWSD's map, then it is scanned for attacks. This means that we could very easily associate an identied attack with the EWSD that originated the CRA that revealed it.

Trigger-Quota

This proposal would see each EWSD allocate a periodic quota for each identity (ASN)

it knows for other EWSDs (through certicates). This quota states how much attacks an EWSD is allowed to reveal. When an EWSD's quota is used up alerts triggered by his CRAs are ignored.

Trigger-Decay
trigger e.g. an attack.

Identify the rate of attacks that we consider to be average/normal for each EWSD to 2 attack per hour. Keep the latest time at which each source EWSD has revealed

Exponentially decay the amount of attacks that an EWSD can trigger (probability of

accepting the attack). If the decayed probability is less then some threshold then do not alert on it (say 30.00%). This is a dierent approach that aims at CRAs as he sustains his possibly malicious behavior.

rapidly decaying our trust for an EWSD's

if 1 e2(timelast attack) < 0.3 = reject

43

In the case that an EWSD was genuinely triggering many alerts we believe there should be some other EWSD whose AS was also aected by these attacks and hence we can still detect them from his CRAs. For this to work we must ensure that if multiple EWSDs trigger the same alert we only decay/modify quota on one of them.

Clever BGP attacks

There are two options for an attacker who attempts to make his mounted BGP attacks go undetected by manipulating BGP itself. The rst option he has is to ensure that his attack does not attract

any

AS

running an EWSD. This means that no perspective(CRA) sent over the EWSD net will hold information that can reveal his attack. This is a complex and dicult option as the attacker has no control over the routing decisions taken outside of his domain. However, as explained in (Section 1.2), the more information the attacker has about other ASes the more likely he can mount such a strategic attack. The alternative option is for the attacker to mount BGP attacks against the IP address of the EWSD running on his target's AS. The attacker does this with the intent of diverting all information destined for that EWSD to him, this means that his target EWSD will not be capable of detecting any of his mounted attacks. However, our design also makes this option extremely dicult. Inter EWSD communication

happens through ooding, so the attacker must ensure that his BGP attack(s) attracts every single AS running an EWSD that his target has P2P sessions with. Otherwise EWSDs neighboring his target can still communicate with it. An attacker

may

be able to identify the EWSDs whom his target has P2P

sessions with. He may be able to do this by analyzing the paths, within his routing protocol overlay, heard for his target's identity(ASN). However, our random peering mechanism means that an EWSD's neighbors are randomly distributed over the Internet, this makes it very dicult for the attacker to attract all of them.

6.4.2 Third party detection

Now we take a look at our solution's ability to perform third party attack detection. Previously we analyzed an EWSD's ability to detect attacks against its own AS (First party detection). Recall our solution's third party detection mechanism (Section 5.11.3). when a new untrusted route is seen for This mechanism is intended to allow an EWSD to detect However, from our analysis we have found that our

any prex.

third party detection mechanism can be easily bypassed by an attacker. Furthermore, it is only eective in detecting third party indirect prex hijack attacks.

44

Our third party detection mechanism works quiet well for indirect prex hijacks. If the attack makes it into any perspective exchanged over the EWSD net then it will denitely be detected by all EWSDs [Figure 26]. This is because indirect attacks claim a new peering with their target's AS. If such a route/attack is seen by any EWSD it introduces a new triple,

with no/little history,

within its map.

However,

deaggregation/direct attacks generally introduce no new triples i.e. the attack follows routes previously introduced into an EWSD's map. Furthermore, some prexes are allowed to be deaggregated and likewise some prexes are multi-homed, this means that an EWSD will generate false positives if it tried to detect on deaggregation/direct attacks. We have found that an attacker with access to a malicious EWSD can bypass third party detection altogether i.e. he can ensure that none of his attacks can be detected by anyone but the EWSD associated with his target's AS. To do this the attacker needs to perform an

unused prex hijack (Section 1.3) and

associate with it the path he will use in his future attack. Since this initial attack is against a prex not allocated for use over the Internet, then no EWSD will detect any threat. The attacker keeps his unused prex hijack alive for some time, by doing so EWSDs build trust for all the triples within the routes seen for the unused prex. So the attacker has managed to build trust on a triple that would have otherwise caused his attack to be detected. Third party detection attempts to allows an EWSD to detect attacks against ASes other than its own AS. An example application would be a provider AS detecting attacks against its customers whom have not bought up an EWSD. This takes us onto our nal point regarding third party attack detection. Our solution allows all EWSDs to build exactly the same graph, this gives an EWSD the ability to detect third party attacks as robustly as it can detect attacks against its own AS. However, in order to do so, an EWSD requires some extra information as mentioned in (Section 5.11.1). If an AS agrees to handover this information to another trusted AS running an EWSD, that trusted AS could provide

transitive rst party detection.

This

feature has not been implemented since we believe that it is very unlikely that any AS would handover such sensitive information to

anyone.

6.4.3 EWSD Deployment

The location of an EWSD within the internal topology of an AS is quiet signicant, it has a direct eect on the quality of the perspective that an EWSD can build on behalf of its AS. It does not suce for an

45

EWSD to have a single BGP interface with some router in its represented AS, such a deployment would see EWSDs build very weak perspectives that can exclude attack revealing information. BGP routers

generally prefer a route heard via eBGP over one heard over iBGP when they are both equally good. This means that an AS can partition internally on a prex [Figure 24]. To fully capture an AS's perspective an EWSD must peer with all of its border routers. However, this is an expensive option in terms of

the number of iBGP sessions that an AS must congure. Our recommended deployment strategy is for EWSDs to peer with the leaf routers of the route reector [Figure 4] tree within their AS. This will allow an EWSD to capture a signicant portion of it's AS's perspective; However, it may still omit attack revealing information. We of course refer to logical iBGP peerings instead of physical iBGP peerings for an EWSD. Our recommended minimum requirements for an EWSD machine are as follows:

CPU RAM

4+ Cores , 2.0 GHz + 4 GB+ DRAM

Multiple cores to parallel message verication and processing Holds cached graph data, certicate store and overlay protocol RIB

HDD

256 GB Solid State

Holds an EWSD's built graph and provides fast access to it

6.4.4 Cost and scalability

Our analysis shows that the amount of messages seen by an EWSD grows linearly with the size of the EWSD net. This is generally a good indicator that our solution may be able to scale to full deployment. However, there are more factors to take into concern before we reach such a conclusion.

Prior to analyzing our solution's scalability we would like to quickly comment on [Figure 29]. This gure shows that the amount of messages seen by an EWSD varies quite signicantly, by analyzing the cause

46

of this variance we have found that the operation of our routing protocol overlay (section 5.3) generates ooding hot-spots within an EWSD net. We refer to hot-spots as EWSDs who see high amounts of

redundant messages due to all/most of their P2P sessions being used by our overlay protocol. This shows that although our protocol does reduce the amount of redundant messages seen over an EWSD net, as previously shown in (gure 15), this reduction is not fairly distributed amongst EWSDs. By exploring this variance we have found that,

generally, EWSDs with the highest amount of P2P sessions are hot-spots.

It follows that if an EWSD's FANOUT is reduced they are less likely to be a hot-spot. However, there is a

strict trade-o here between an EWSD's robustness and resilience to attacks described in (section

5.10) and its operational cost. It is worth noting that the amount of hot-spots in an EWSD net is very small but they may suer problems at full scale deployment. To deal with this issue we propose that an EWSD keep track of the redundancy rate within received messages, when it exceeds a certain threshold the EWSD should bring oine some of its P2P sessions. This of-course may mean that our protocol

creates another hot spot when it re-converges, however, with this mechanism the burden of hot-spots will be bounced around the EWSD net

implicitly balancing out our protocols benets.

Scalability analysis
Messages sent over an EWSD net are signed, this means that every single message received needs to be veried, this involves calculating the message hash, decrypting the message signature and verifying the two values match. We mentioned that each EWSD periodically sends its current prospective as seen

though it BGP interfaces, there is a strict trade-o between this periodicity and the cost of our solution. Furthermore, the periodicity of CRA messages also directly eects the delay between an attack taking place and its detection. With these trade-os in mind we have decided that EWSDs should send CRA's hourly. Now we consider the worst case scenario where all EWSDs are synchronized to send their perspectives within the same minute i.e. they are all bought online by their administrators at roughly the same time of day. Can EWSDs handle such loads at full deployment? In order to answer this question we must rst estimate the amount of data that all EWSDs will send combined, recall our suppression modes mentioned in (Section 5.9). As we will explain next our recommended suppression modes are (TRIPLES NOT IN MAP & CLOSEST ONLY). In order to identify how much data we will end up sending with these suppression modes we must rst abstract away from their distributed nature. Our abstraction is that all EWSDs perspectives are accumulated into a single routing table. If our solution was fully deployed, how much of this abstract routing table would actually pass

these suppression lters?

CLOSEST ONLY
For every prex within the abstract routing table, group it's AS-PATHs by their rst hop, for each group send the shortest AS-PATH(s) in length. So with full deployment we will send one path for each prex i.e. the perspective for the AS that owns each prex has the shortest(empty) AS-PATH in our abstract routing table. Now imagine that only X percent of prexes were owned by ASes that we had perspectives for in our abstract routing table i.e. ASes running an EWSDs. As previously described we would only send one path for each of them. However, for

47

each remaining prex there could be many perspectives with equally short AS-PATHs and hence their all sent by this suppression mode. There is a seesaw eect here, at low EWSD deployment, were less likely to have multiple equal length AS-PATHs for a prex, at higher EWSDs deployment, there are more prexes that have only one closest AS-PATH. So we generalize and say that a single AS-PATH is sent for each prex under this mode.

TRIPLES NOT IN MAP

In this mode we would need to send

lowest amount of AS-PATHs that cover all the triples within all

the AS-PATHs seen in the abstract routing table. We believe that the complexity of trying to generate a model by which we can predict this value is equivalent to that of trying to infer policies on the Internet as this value is directly related to the routing policies globally used. Instead we have chosen to make

use of publicly available route monitor data to calculate the exact amount of AS-PATHs that pass this suppression mode in the Internet as it is today. We analyzed routing table dumps for April 2011 from 18 separate route collectors as made available by RIPE RIS [6], a project that collects and stores Internet routing data from several locations around the globe.

Unique ASN 41,082

Total AS-PATHs 30,437,598

Unique AS-PATHs 4,075,845

Unique Triples 1,201,105

Passed Suppression 1,121,190

Our analysis of the routing tables showed that ~1.1 million AS-PATHs pass this suppression mode. This number reects the minimal amount of AS-PATHs needed to be sent to cover all the triples within the Internet. Our suppression mode implementation implicitly guarantees this property i.e. The only way an AS-PATH will pass this suppression/re-suppression mode is if it has the

only

reference to some triple,

this means that longer paths with more triples cause shorter ones to fail this mode. Accommodating for the rapid growth in the Internet, we assume that at full scale deployment 1 million prexes are advertised over BGP (currently 489,046 [7]). We also assume that the amount of AS-PATHs needed to be sent for the TRIPLES NOT IN MAP suppression mode doubles as the Internet becomes more topologically complex due to more ASes coming online. Doubling this value also accommodates for the fact that our analyzed route monitor data was not a full representation of the Internet and may have omitted triples. Hence, with our recommended suppression modes, EWSDs will cooperatively send an

estimated 3.2 million AS-PATHs. Each AS-PATH will consumes on average 10 bytes within a CRA, 4 for the prex it is associated with and 5 for the actual path (average AS-PATH length on the Internet[7]). This means each EWSD, at full scale deployment, should receive

per hour.

32 MB of unique CRA messages

It turns out that with a fairly dense variable sized EWSD net, using our routing protocol overlay, 20% of messages sent over it are redundant[Figure 16]. This gure should, with our proposed hot-spot bouncing mechanism, reect the average amount of redundant messages seen by an EWSD. Our research shows that the recommended size of RSA keys/certicates is 2048 bit keys with an associated decryption time of 7ms on an general purpose Intel 1.8GHz dual core processor. We also found that this processor can perform SHA-256 hashes at a rate of approximately 100 MB/s [10]. The following formula is a somewhat primitive model of how long it will take an EWSD to verify CRA messages sent from all others EWSDs in the EWSD net periodically.

48

redundancy

EW SDs decryption time total data + #cores hash(rate)

1.2

42, 000 0.007 32 + 4 100

89s

Hence we expect that verifying messages, under the worst case scenario previously described, on an EWSD machine will utilize 2.5 % of its hourly capacity. In summary our

estimates

show that the amount of

data sent periodically over an EWSD net, with full deployment, is manageable. Furthermore, the

case time spent processing this data is well within an EWSD's capacity.

worst

[Figure 28-29] show that combining suppression modes (1 & 2) combined is the best trade-o between the amount of attacks that can be detected from the graphs built at EWSDs and the cost of building them.

6.4.5 Stopping Attacks

The main emphasis of this project was to build a system that can

detect

attacks.

Now that we have

achieved our aim can we transform our system into one that can stop attacks. It turns out that we could quiet easily do so with little to no changes to our solution. Simply when an EWSD detects an attack they can ood an authoritative alert over the EWSD net, when such an alert is received by an EWSD, it will perform some sanity/validity checks and send over its iBGP sessions one of it alternative paths(if any), for the target prex, with a high LOCAL-PREF and a third party next-hop (the IP address of the router the alternate path was heard from). However, the existence of false positives and further security issues as with key hijacking means that we would be just adding to BGP's security issues. Furthermore, it will be extremely naive of us to think that an AS would run such a system that can interfere with its internal operation.

49

Conclusion and Evaluation

7.1 How well does it work

From our analysis we have shown that our solution, as a single entity, is comparable to S-BGP in terms of its ability to detect attacks. Our solution's BGP threat and attack detection (Section 5.11) mechanisms allow an EWSD to detect when an invalid peering is claimed with its AS over BGP. This peering can be invalid because it does not exist or it exists but its use violates the routing policies known by the EWSD. Combining these mechanism from all EWSDs means that our solution, as a whole, can provide

validation.

Similarly, our solution as a whole can provide

origin authentication.

route

Our solution diers from S-BGP in that its individual instances (EWSDs) can only eectively detect attacks against their own AS (rst party detection). Furthermore, in order to detect these attacks, EWSDs rely solely on information heard from one another. On one hand this is a disadvantage in that ASes have

little to no incentives to be the rst ones to deploy an EWSD. However, we have worked hard to ensure that our solution is cheap and easy to deploy for an AS, and we believe that that this should counter this disadvantage. We have also shown that an EWSD can detect

most/all attacks against its AS when

deployment levels are at 20-40% depending on the topology of the EWSD net, this is another incentive that should spur deployment. We have shown that at full scale deployment, where we liken our ability to detect attacks to S-BGP, the operational cost of a solution instance should be generally manageable and well within the budget of even the smallest ASes in the Internet. However, our scalability analysis has uncovered a scaling issue for a

very small subset of solution instances, namely our routing protocol's hot-spot phenomena, however, we
are condent that our proposed hot-spot bouncing mechanism should neutralize this problem. This leads us to a conclude that, with this mechanism in place, our solution can scale to full deployment. The distributed nature of our solution and our avoidance of authoritative/secure data sources e.g. (Public key infrastructure) means that we have traded security for deployability. It follows that there are some security issues with our solution, although we have implemented/proposed functionality that seriously mitigate their threat, their existence has limited our solution to be one that can detect and not stop attacks. We believe that, with our proposed features, there are no major obstacles as to why our solution cannot be

widely adopted by ASes.

Realistically our solution will in time become redundant when ASes nally

begin switching to secure implementations of BGP. In the meanwhile we believe that our solution provides an alternative feasible approach to providing some degree of security for ASes. In summary, our solution is cheap, scalable, deployable, eective and

reasonably

secure. However, our

solution does not and cannot (practically) solve/stop prex hijacking attacks, it can just detect their presence and provide warnings to the victims as early as possible.

50

7.2 Future work

The following is a summary of some future work we propose to extend our solution

Explore alternative proposals by which an AS can agree on initial EWSD peerings Hard state redesign of our solution to substantially decrease the periodic loads seen by an EWSD Explore a dierent approach to performing third party attack detection Implement the proposal described in our analysis to suppress false positive attacks Implement our proposed hot spot bouncing mechanism and verify it works

7.3 Self evaluation

We started this project with a single abstract aim, to provide security for BGP independent of its implementation layer, and a general approach by which we though we can achieve this aim. In the process of realizing our aim we encountered many obstacles that we had to overcome due to which our solution became increasingly complex. Our initial idea was for each instance, now termed an EWSD, to detect and actively resolve, by communicating with other EWSDs, any attack that it can see over its iBGP sessions. However, we found that an alternative approach would yield much better results where EWSDs should detect attacks against their own AS by analyzing information heard from one another. It was our intuition that by eectively transposing our initial approach we can detect attacks correctly without sharing sensitive information i.e. with our initial approach an EWSD could not correctly identify an attack against other ASes if it did not hold sensitive information such as their routing policies and peering relationships. We took an agile approach toward our implementation, this was due to the fact that our requirements were in continuous evolution, the more we implemented the more issues revealed them self that we had to address. We believe that this approach was suitable for such an experimental project. In hindsight we feel that the trust model between EWSDs should have been further developed, such that EWSDs should vouch for one another and atop this mechanism an EWSDs can decide how much they can trust information heard from one another. Our current trust model penalizes overly good EWSDs, those exposed to many attacks in close succession, and does not dierentiate between them and an actual malicious EWSD. Overall we believe that our nal solution, including the proposed functionality whose need was revealed by our analysis, is a feasible realization of our aim.

51

8
[1]

Bibliography
S. Goldberg, M. Schapira, P. Hummon, J. Rexford How Secure are Secure Interdomain Routing Protocols? SIGCOMM '10 Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM [2] G. Goodell, W. Aiello, T. Grin, J. Ioannidis, P. McDaniel, A. Rubin Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing Proc. of Internet Society Symposium on Network and Distributed System Security (NDSS'03), 2003. [3] S. Kent, C. Lynn, K. Seo Secure border gateway protocol (S-BGP) IEEE Journal on Selected Areas in Communications, 18(4):582592, April 2000. [4] R. White Securing BGP through secure origin BGP. Technical report, Internet Protocol Journal, Cisco Systems, September 2003. [5] M. Lad, D. Massey, D. Pei, Y. Wu, B. Zhang, L. Zhang PHAS: A prex hijack alert system in Proc. USENIX Security Symposium, 2006. [6] RIPE RIS RIS Raw Data http://www.ripe.net/data-tools/stats/ris/ris-raw-data [7] RIPE RIS Statistics Report 2011-04-15 - 2011-04-22 http://www.ris.ripe.net/weekly-report/reports/risreport-20110415-20110422.txt [8] [9] AS6447 BGP Routing Table Analysis Report http://bgp.potaroo.net/as6447/ B. Kaliski TWIRL and RSA Key Size http://www.rsa.com/rsalabs/node.asp?id=2004

[10]

W. Dai Crypto++ 5.6.0 Benchmarks http://www.cryptopp.com/benchmarks.html

52

Early Warning System for the Border Gateway Protocol

Appendix

University College London, Department of Computer Science

1

Contents
1 Project Plan 2 Interim Report 3 RIPE RIS Analysis 4 Simulator Requirements 5 Simulation Server
5.1 5.2 5.3 5.4 Automatic Topology Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Topology Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example topology conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 5 7 7 7
7 8 13 14

6 Simulator Client
6.1 6.2 Connecting to the simulation server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commanding the simulation server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14
14 14

7 Other information
7.1 7.2 Modifying Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16
16 16

8 Code Listing
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Code listings summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attacker.py code listing BGP.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19
19 19 20 23 29 32 37 39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BGP_Structures.py Daemon.py Graph.py PVP.py

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Project Plan

Interim Report

RIPE RIS Analysis

To reproduce our RIPE RIS analysis results, carry out the following steps

1. 2. 3.

Navigate to the /ripe folder in our provided distribution Execute gcc -o dumper dump_paths.c bgp_lib/libbgpdump.so -Wall Execute ./dumper
This will result in approximately 1GB of uncompressed data being dumped into /ripe/as_paths

4.

Execute python process_dump.py

We have included April 2011 routing table dumps from route collectors at the following locations: Amsterdam, Frankfurt, Geniva, Japan, London, Miami, Milan, Moscow, New York, Palo Alto, Paris, Sweden, Vienna To add new/updated routing table dumps, place the new routing table dumps in the /ripe/bgp_tables folder. Routing table dumps can be retrieved from the following website: http://www.ripe.net/data-tools/stats/ris/ris-raw-data

Simulator Requirements
To run our simulator, this is a critical requirement. http://www.python.org/download/releases/2.6/

Python-2.6

GraphViz

To convert a clients image request response into an actual image from dot text http://www.graphviz.org/Download.php

RSA-1.3.3

Used by our EWSD implementation to generate RSA keys, verify and sign messages Provided in the distribution folder /dependents To install,

execute easy_install rsa-1.3.3-py2.6.egg

Matplotlib

Used by our automated analyzer to display results of analysis runs. All results are displayed graphically using this library http://matplotlib.sourceforge.net/users/installing.html

Simulation Server

5.1 Automatic Topology Conguration

Our simulator takes as input a conguration le located at ews/cong/topology.cong relative to the distribution folder, this le can be automatically generated using our generator script. The generator script

takes as input

another

conguration le at ews/cong/generator.cong, within this le are congurable The following are the attributes and

parameters that are used by the script to generate the topology. there purpose FANOUT

Integer Integer Float Float Float Integer

Number of tier 1 ASes in the conguration, dictates the size of the whole topology. (

NOT EWSD RPR FANOUT)

ROUTERS_PER_AS

Number of routers each AS within the simulation has. If above 1 a route reector is used in each AS

T2_PEER_PROBABILITY

The probability that a tier 2 AS brings up a peering class BGP session with another tier 2 AS

T3_PEER_PROBABILITY

The probability that a tier 3 AS brings up a peering class BGP session with another tier 3 AS

DAEMON_PROBABILITY

The probability that an AS should have an EWSD online e.g. 1.0 means full deployment

DAEMON_MAX_PEERS

The maximum number of P2P sessions each EWSD should bring up initially

This module can also be used directly by code as with our attacker module. To do so the user overrides the map holding these attribute values prior to calling the actual generation function. The user can then re-start the simulator, which will now read the new topology le. To invoke the generator script :

execute python Generator.py

5.2 Manual Topology Conguration

This section details how one can write their own topology in our chosen syntax. Topologies should be written to the conguration le located at ews/cong/topology.cong relative to the distribution folder.

Declaring ASes
Description Command Example Note Description Command Example Description Command Example
This command declares the range of ASNs to instantiate into the simulation. An AS will be instantiated for each AS

as-init [from-ASN..to-ASN or ASN],...... as-init 65000..66000,900,905..909

This should be the rst declaration within the conguration

Declaring standard BGP router

This command declares a BGP router under some AS

router [IP] at-as [ASN] router 160.10.0.1 at-as 65400

Making a router a route reector

This command changes the status/operation of a declared BGP router into that of a route reector

route-reector router 160.10.0.1 at-as 65400 route-reector

8

Declaring a network
Description Command Example
This command declares a network address for a BGP router to announce over BGP within the simulation

network [CIDR IP] router 160.10.0.1 at-as 65400 network 169.10.9.0/24 network 169.10.0.0/16

Declaring a peering
Description
This command declares a peering between one BGP router and another within the conguration. Peerings can be declared and tagged with a community , and also assigned a metric (for iBGP). Peerings with routers declared under the same AS are automatically detected and instantiated as iBGP sessions

Command Example

Note

peer [declared BGP router IP of peer] [class COMMUNITY] [metric VALUE] router 160.10.0.1 at-as 65400 peer 209.210.9.1 peer 106.10.0.2 metric 100 peer 106.10.0.3 metric 50 class clique-a peer 100.293.1.1 class provider Community tags must be declared within the conguration le, refer to the policy command.
The target router of this command must agree on this peering, i.e. they must also have a command to bring up a BGP session with this router

Declaring LOCAL-PREF lters

Description Command
This command declares LOCAL-PREF lters under a BGP router, this router will then apply these lters within its BGP simulation local pref on all prexes heard from a neighboring AS

local-pref [value] next-hop-as [ASN]

local pref on all prexes heard from a router at a neighboring AS

local-pref [value] next-hop [IP]

local pref on a particular prex heard from a neighboring AS

local-pref [value] prex [prex] next-hop-as [ASN]

local pref on a particular prex heard from a router at a neighboring AS

local-pref [value] prex [prex] next-hop [IP] Example

Example prefer a customer's routes over provider's except for a single prex

router 160.10.0.1 at-as 65400 peer 209.210.9.1 class provider peer 65.190.90.1 class customer peer 106.10.0.2 metric 100 local-pref 90000 next-hop 65.190.90.1 local-pref 10000 next-hop 209.210.9.1 local-pref 90000 prex 23.0.0.0/8 next-hop 209.210.9.1
The commands have been listed in order of precedence, i.e. when multiple lters apply for the same received announcement, the rule towards the end of the list will be applied.

Note

Declaring MED lters

Description Command
This command declares MED lters under a BGP router, this router will then apply these lters within its BGP simulation Set MED value for all routes sent to a neighboring/peered router

MED [value] to-router [IP]

Set MED value for all routes sent to a neighboring/peered AS

MED [value] to-as [ASN]

Set MED value for all routes for a particular prex sent to a neighboring/peered AS

MED [value] on-prex [prex] to-as [ASN]

Set MED value for all routes for a particular prex sent to a neighboring/peered IP

MED [value] on-prex [prex] to-router [ASN] Example

Example, inuence a neighboring AS,connected at two separate locations, to choose one path/exit point over the other except for a particular prex

router 160.10.0.1 at-as 65400 network 160.10.8.0/24 peer 160.10.0.5 metric 100 peer 209.210.9.1 class provider MED 900 to-router 209.210.9.1 MED 100 on-prex 160.10.0.0/16 to-router 209.210.9.1 160.10.0.15 at-as 65400 peer 160.10.0.1 metric 50 peer 209.210.9.3 class provider MED 400 to-router 209.210.9.3 Note
The commands have been listed in order of precedence, i.e. when multiple lters apply for the same received announcement, the rule towards the end of the list will be applied.

Declaring MED Ignore lters

Description Command
This command declares lters to ignore heard MED values under a BGP router, this router will then apply these lters within its BGP simulation Ignore all MED values heard

MED ignore all

Ignore all MED values heard from a neighboring AS

MED ignore next-hop-as [ASN]

Ignore all MED values heard from a particular router at a neighboring AS

Example

MED ignore next-hop [IP] router 160.10.0.1 at-as 65400 peer 160.10.0.5 metric 100 peer 209.210.9.1 class provider MED ignore next-hop 209.210.9.1
The commands have been listed in order of precedence, i.e. when multiple lters apply for the same announcement, the rule towards the begining of the list will be applied.

Note

10

Declaring a routing policy

Description Command Example
This command declares a routing policy that can then be used as COMMUNITY tag when declaring peerings

policy [name] [shape (used for GraphViz rendering)] no-ad [policy name]
Declaring the standard policy model, routes tagged with provider or peer COMMUNITY i.e. heard from a provider/peer link, should not be forwarded on links with a provider/ peer tag

Note

policy provider box no-ad provider no-ad peer policy peer odot no-ad provider no-ad peer policy customer box policy None none policy None none , must be included in the le, or the simulator will crash.
[shape] attribute is the shape that will be used by GraphViz to render a link end with the particular policy tag, you have a choice of the following shapes: inv, dot, invdot, odot, invodot, tee, invempty, diamond, odiamond, ediamond, crow, box, obox, open, halfopen, vee, none

Declaring EWSD BGP router

Description Command Example
This command declares an EWSD router under some AS, exactly the same as a normal BGP router except that it will not forward heard routes , and that it runs an EWSD.

router [IP] at-as [ASN] daemon router 160.10.0.1 at-as 65400 daemon #BGP Interfaces peer 160.10.0.2 peer 160.10.0.2
EWSD routers should be congured with extra information as mentioned in the report (Sesction 5.11.1) and also with the initial P2P sessions of the EWSD. The following commands detail how this can be done.

Note

Declaring EWSD P2P Sessions

Description Command Example
This command declares the initial P2P sessions (Report: section 5.2.1) that this EWSD should attempt to bring up.

connect [EWSD IP] router 160.10.0.1 at-as 65400 daemon ..... connect 90.0.0.2 connect 191.9.0.1
The target EWSD of this command must agree on this peering, i.e. they must also have a command to bring up a P2P session with this EWSD

Note

11

Declaring EWSD list of peers

Description Command Example
This command declares/congures this EWSD with the ASNs of all ASes connected to the AS running this EWSD.

as-peers [ASN:COMMUNITY TAG],... router 160.10.0.1 at-as 65400 daemon ..... connect 90.0.0.2 as-peers 19223:provider,8772:customer,1882:customer connect 191.9.0.1
This is required to correctly detect indirect prex hijack attacks

Note Description Command Example

Declaring EWSD atomicity list

This command declares/congures this EWSD with the set of prexes that are allowed to be deaggregated i.e. should not warn on deaggregation attacks for them

deaggregated [CIDR IP],... router 160.10.0.1 at-as 65400 daemon ..... connect 90.0.0.2 deaggregated 19.0.0.0/16,18.0.0.0/24
This is required to correctly detect deaggregation prex hijacks

Note Description Command Example Note

Declaring EWSD simulation suppression lters

This command declares/congures the suppression lters that should be used by EWSDs within the simulation

suppression-modes [mode 1/2/3],.. suppression-modes 1,2

This should be declared outside of an EWSD, we recommend declaration after as-init. 1 : CLOSEST ONLY (Report: section 5.9.3) 2 : TRIPLES NOT IN MAP (Report: section 5.9.2) 3 : NOT SUBSET OF CLOSEST (Report: section 5.9.4)

12

5.3 Example topology conguration

as-init 1..9,10 suppression-modes 1,2 router 60.0.0.0 at-as 5 network 60.0.0.9/31 peer 65.0.0.0 peer 20.0.0.0 class provider peer 60.0.0.1 local-pref 500 prex 10.0.0.0/8 next-hop 20.0.0.0 router 65.0.0.0 at-as 5 network 65.0.0.0/8 peer 55.0.0.0 class customer peer 60.0.0.0 peer 60.0.0.1 local-pref 10000 prex 10.0.0.0/8 next-hop-as 3 router 55.0.0.0 at-as 3 network 55.0.0.0/8 network 55.0.0.0/16 peer 65.0.0.0 class provider peer 70.0.0.0 class peer peer 80.0.0.0 class peer peer 10.0.0.0 class peer router 70.0.0.0 at-as 6 network 70.0.0.0/8 peer 55.0.0.0 class peer router 80.0.0.0 at-as 7 network 80.0.0.0/8 peer 55.0.0.0 class peer peer 90.0.0.0 peer 90.0.0.1 router 90.0.0.0 at-as 7 network 90.0.0.0/8 network 90.1.0.0/16 peer 80.0.0.0 peer 35.0.0.0 class customer peer 90.0.0.1 router 10.0.0.0 at-as 1 network 10.0.0.0/8 peer 55.0.0.0 class peer peer 10.20.0.0 router 10.10.0.0 at-as 1 network 10.10.0.0/8 network 10.10.0.0/16 peer 10.20.0.0 metric 15 peer 20.0.0.0 class provider MED
5000

to-router

20.0.0.0

router 10.20.0.0 at-as 1 route-reector peer 10.0.0.0 peer 10.20.0.1 peer 10.10.0.0 metric 15 peer 10.30.0.0 metric 10 router 10.30.0.0 at-as 1 network 10.30.0.0/8 peer 10.20.0.0 metric 10 peer 20.0.0.0 class provider MED 0 to-router 20.0.0.0 router 20.0.0.0 at-as 2 network 21.0.0.0/8 peer 60.0.0.0 class customer peer 10.10.0.0 class customer peer 10.30.0.0 class customer router 35.0.0.0 at-as 10 network 35.0.0.0/8 peer 35.0.0.1 peer 90.0.0.0 class provider router 35.0.0.1 at-as 10 daemon peer 35.0.0.0 connect 10.20.0.1 as-peers 7:provider router 10.20.0.1 at-as 1 daemon peer 10.20.0.0 connect 90.0.0.1 connect 35.0.0.1 as-peers 2:provider,3:peer router 90.0.0.1 at-as 7 daemon peer 90.0.0.0 peer 80.0.0.0 connect 60.0.0.1 connect 10.20.0.1 as-peers 3:peer,10:customer router 60.0.0.1 at-as 5 daemon peer 60.0.0.0 peer 65.0.0.0 connect 90.0.0.1 as-peers 3:peer,2:provider policy peer open no-ad peer no-ad provider policy provider odot no-ad peer no-ad provider policy customer box policy
None none

13

5.4 Starting the simulation

After the topology has been congured, manually or automatically, the simulation server can be started by entering the following command

execute python Simulator.py

This command will start the simulation, and will also start the multi-threaded TCP server on this server is an interface from which simulation section 4).

clients can access/manipulate the simulation (Report:

port 50008,

Simulator Client

6.1 Connecting to the simulation server

To connect to a simulation server running on some machine, invoke the client script located at ews/Client relative to the distribution folder. The code is invoked with parameters that identify the machine and

port the simulation server is running on

execute python Node.py [address] [port]

python Node.py localhost 50008 | python Node.py 50008 Once connected and displayed the welcome message you can begin to command the server.

6.2 Commanding the simulation server

View global topology information
Description
This command allows you to view the whole topology currently being simulated. using some well known parameters this command can produce dierent views (graphical/text, abstract/concrete)

Command

Example

global [-i] [-a] [-t prex] [-d] -i: graphical view -a: abstraction, i.e. the graphical view at AS granularity -t: prex trace, overlays a graphical trace for a prex within the view -d: Overlay P2P sessions within the view # global # global -i # global -i -a -t 10.0.0.0/8
The parameters [-a][-d][-t] only apply when the global view is requested as a graphic i.e. [-i] is provided. If the requested view is graphical, the resulting GraphViz text returned by the server is complied locally and stored in the same folder as the client script

Note

14

View AS topology information

Description Command Example Description
This command allows you to view all the routers under an AS and a summary of there conguration

as [ASN] as 19282

View router information

This command allows you to view all the information relative to some router within the simulation. This information includes the following Pretty print of the routers current BGP routing table Peerings of this router and there attributes EWSD ag, tells you if this router is also running an EWSD instance Route reector ag, tells you if this router is actually a route reector

Command Example Description

router [IP] router 193.98.2.1

View EWSD information

This command allows you to view information specic to an EWSD running on some router within the simulation. This information includes the following Information regarding the EWSD's detected attacks and there cause Information regarding the EWSD's current conguration and attributes Graphical representation of the EWSD's current graph of the Internet

Command

daemon [IP] [-i] [-t prex] IP: IP address of the router running the EWSD -i: indicates that the request is for an image of the EWSD's graph -t: indicates that the request if for an image of all the routes within the current
EWSD's graph for a particular prex, must be used with [-i]

Example

# daemon 190.0.0.1 # daemon 190.0.0.1 -i # daemon 190.0.0.1 -i -t 10.0.0.0/8

The parameters [-t] only applies when the EWSD's graph image is requested i.e. [-i] is provided. If the requested view is graphical, the resulting GraphViz text returned by the server is complied locally and stored in the same folder as the client script

Note

Live route withdrawal

Description
This command allows you to withdraw a prex from some router within the topology and announce its withdrawal implicitly or explicitly depending on BGP operation. The simulation is

live and hence withdrawals should eect it, the eects of the injection can then be seen with
the array of commands we previously detailed.

Command Example

withdraw [prex] at [IP] # withdraw 190.0.0.0/16 at 19.0.2.1

15

Live route injection

Description
These commands allows you to inject a route,for some prex, into some router within the topology. The simulation is

live and hence injected routes should eect it, the eects of the

injection can then be seen with the array of commands we previously detailed.

Command

Injects a prex,with an empty AS-PATH, into some routers BGP table.

new-net [prex] at [IP]

Injects a prex,with a dened AS-PATH, into some routers BGP table. used mainly to perform indirect prex hijacks.

Example Note

mod-net [prex] [AS-PATH] at [IP] # new-net 21.0.0.0/16 at 21.0.0.1 # mod-net 19.0.0.0/16 9882,4322 at 21.0.0.1
Our BGP simulation dictates that a router prepends the ASN of there AS to the AS-PATH of routes on there announcement

over eBGP and not on there receipt.

Other information

7.1 Modifying Simulation Parameters

To modify parameters within our simulation such as the periodicity of EWSD events, switching on/o RSA signatures, switching on/o routing protocol overlay, edit the

instance variables of the Daemon/Daemon.py and Globals.py modules relative to the folder ews/. Within these modules you will nd
an explanation code annotations of what each instance variable is used for within our simulation. To view the code annotations of these modules in a user friendly manner open the

index.html le and navigate using the tree structure, on the left hand-side of the screen, to these modules.

documentation/

7.2 Analysis
Our analyzer/evaluator module, an automated client, is a wrapper for our simulation server. It invokes the dierent modules of our code base to automatically execute analysis tests, once these tests are complete there results are displayed graphically to the user. To execute a chosen analysis , navigate to and execute python Attacker.py To choose the test to run you must edit Attacker.py's main method located at the end of the le. Within this method, uncomment tests you would like to run and ensure all other tests are commented out. Below you will nd a list of the tests we have provided and there input parameters

ews/ folder

16

Description

General attack detection

Schedules simulations and injects BGP attacks within them, it then collects results aimed at nding the correlation between the amount(percentage) of EWSD's running and the percentage of attacks they collectively detected

Method Parameters

general_attack_detection modes fanout

list of the attack types to simulate and gather data for the fanout attribute to instantiate the automated topology generator with, i.e. implicitly dictate the size of the tested topology (Appendix: section 5.1)

seeded

Indicates if the EWSD deployment and growth should be seeded or not (Report: section 6.3)

Description

Fixated attack detection

Schedules simulations and injects BGP attacks within them, it then collects results aimed at nding the correlation between the amount(percentage) of EWSD's running and the percentage of attacks EACH EWSD can detect against it.

Method Parameters

xated_attack_detection modes fanout

list of the attack types to simulate and gather data for the fanout attribute to instantiate the automated topology generator with, i.e. implicitly dictate the size of the tested topology (Appendix: section 5.1)

seeded

Indicates if the EWSD deployment and growth should be seeded or not (Report: section 6.3)

Description

Third party attack detection

Schedules simulations and injects BGP attacks within them, it then collects results aimed at nding the correlation between the amount(percentage) of EWSDs running and the percentage of third party attacks an EWSD within the topology can detect. The attacks executed are only indirect hijacks, the reasons for this are explained in (Report: section 6.4.2).

Method Parameters

third_party_attack_detection fanout seeded

the fanout attribute to instantiate the automated topology generator with, i.e. implicitly dictate the size of the tested topology (Appendix: section 5.1) Indicates if the EWSD deployment and growth should be seeded or not (Report: section 6.3)

17

Description

Suppression benets
Schedules simulations, then collects results from these simulations aimed at nding the correlation between the following
Activated suppression modes and attacks detected Activated suppression modes and the solution cost in terms of CRA size and

frequency

Method Parameters

suppression_analysis modes fanout

list of the attack types to simulate and gather data for the fanout attribute to instantiate the automated topology generator with, i.e. implicitly dictate the size of the tested topology (Appendix: section 5.1)

daemon_rate

The EWSD deployment percentage within the simulated topologies

Description

General solution cost

Schedules simulations, then collects results from these simulations aimed at nding the correlation between the growth of the EWSD net and the amount of messages sent over the EWSD

Method Parameters

general_cost_detection max_fanout daemon_rate

dictates the maximum FANOUT to analyze for message counts, i.e. analyze all the topologies with FANOUT attribute less then this value The EWSD deployment percentage within the simulated topologies

Description

Routing protocol overlay & SEQNO benets

Schedules simulations, then collects results from these simulations aimed at nding:
the correlation between the size of the EWSD net and the reduction in the amount of messages sent over a fairly dense EWSD net when using our overlay protocol. the correlation between the size of the EWSD net and the reduction in the amount

of messages processed within the EWSD when using SEQNOs

Method Parameters

overlay_seqno_cost_reduction max_fanout daemon_rate

dictates the maximum FANOUT to analyze for message counts, i.e. analyze all the topologies with FANOUT attribute less then this value The EWSD deployment percentage within the simulated topologies

18

Code Listing

8.1 Documentation
We have provided with this distribution a detailed documentation of our code base, this documentation describes the modules/classes within our system, there parameters, instance variables, and purpose. To view this documentation navigate to the

/documentation folder relative to the distribution folder, then

open index.html

8.2 Code listings summary

Due to the size of our code base, approximately 4000(5000 with comments) lines of code, which roughly maps to 100 pages of code, we will only list the most interesting parts of interesting modules within our code. First we would like to give a very brief over view of the modules within our system and their purpose. We have also highlighted the modules that we will include some code for.
Lines

Attacker.py Autonomous.py BGP.py BGP_Structures.py

Client

Carries out automated analysis tests Contains description of a AS within the simulation Contains description of BGP operation within the simulation Contains support structures for BGP simulation Simulation client Initializes/Manipulates/Queries the simulation topology Cryptographic component of the daemon solution Contains the description of the EWSD main controller component Graph component of the daemon solution Contains path vector implementation of our overlay protocol Contains distance vector implementation of our overlay protocol Contains link state implementation of our overlay protocol Contains support structures for Early waning system components Generates topologies Holds variables global to the simulation Contains (graphical/text) output generating functions Code performance prole viewer Contains description of a router within the simulation Contains live logging functionality Simulation server

922 58 370 171

Node.py Conguration.py
Daemon

72 715

Crypter.py Daemon.py Graph.py

Protocols

117 518 405

PVP.py DVP.py LSP.py Structures.py Generator.py Globals.py Printer.py Prole.py Router.py Statistics.py Simulator.py

193 90 91 143 353 67 497 15 166 93 162

In summary, we have included approximately we have listed approximately listings reect the segments of code that we believe to be interesting.

of detail, please refer to our distribution folder /ews for the full code
19

25% of our code base, our Our listings omit a vast amount

8.3 Attacker.py code listing

For this module we will list one of the automated analysis methods ( have implemented and part of the

draw()

xated_attack_analysis())

we

method which displays the results of this analysis. We have

only included a single example because we feel that it is sucient to show how we have wrapped our simulators code to automate our analysis.

Listed :
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 #

20% of module code

def

f i x a t e d _ a t t a c k _ d e t e c t i o n ( modes , f a n o u t , s e e d e d ) : """ Schedules finding of simulations corelation and injects the BGP attacks within them , of it then collects and results the aimed at

the

between detect the

amount ( p e r c e n t a g e ) it . to simulate

E S 's W D

running

perecentage

attacks

EACH E S W D can L{ l i s t } The of

against

@param @param @param """

modes : fanout : seeded :

attack

types to

and

gather

data

for generator or not with

fanout

attribute if the

instantisate and

the

automated should

topology be seeded

Indicates

E S W D

deployment

growth

import
# fileno #

Simulator , Generator , Globals , S t a t i s t i c s , C o n f i g u r a t i o n , generated under this test will be stored in some

Daemon random file

Topologies =

s t r ( i n t ( random ( ) the

100000))
that will hold the results of this test

Instantiate mode

variables

for

in

modes : = {0:[0 ,0 ,0] ,1:[0 ,1 ,0]} = = = be [] [] [] used by the test runs

FIXATED_DETECTION [ mode ]

DETECTION_TIER_DIST [ ' T1 ' ] [ mode ] DETECTION_TIER_DIST [ ' T2 ' ] [ mode ] DETECTION_TIER_DIST [ ' T3 ' ] [ mode ] Generate an initial topology , to

Generator . clean_state ( ) G e n e r a t o r . CONFIG = { "F N U A O T" "ROUTERS_PER_AS" "T2_PEER_PROBABILITY" "T3_PEER_PROBABILITY" "DAEMON_PROBABILITY" "D E O _ A _ E R A M N M X P E S" G e n e r a t o r . g e n e r a t e ( s e e d e d , f i l e n o , True ) # Run the test for deployment levels between 0 : fanout , :1 , :0.6 , :0.3 , :0 , :5} # Initially no E S ' s W D running

100%

in

steps

of

10%

for

i i

in

range ( 0 , 1 0 ) :

+ = 1

Simulator . clean_state ()

if

seeded #

: topologies grow around the seed , the generator has a special function for this

Seeded

Generator . increase_seed_radius ( f i l e n o ,

i / 1 0 . 0 , True )

else
#

: If its not seeded then just generate a new random topology

Generator . clean_state ( ) G e n e r a t o r . CONFIG = { "F N U A O T" "ROUTERS_PER_AS" "T2_PEER_PROBABILITY" "T3_PEER_PROBABILITY" "DAEMON_PROBABILITY" "D E O _ A _ E R A M N M X P E S" G e n e r a t o r . g e n e r a t e ( s e e d e d , f i l e n o , True ) # Run each type of attack with this topology : fanout , :1 , :0.6 , :0.3 , : i /10.0 , :5}

for

mode #

in

modes : the simulagtors previous state , then reload / load the topology to be tested

Clean

Simulator . clean_state () C o n f i g u r a t i o n . l o a d _ t o p o l o g y ( " c o n f i g / "+ f i l e n o )

20

209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267

command = # List of =

C o n f i g u r a t i o n . process_command routers within the topology not running an E S W D and not route reflectors

routers

[ ( i p , o b j e c t . as_number )

not
# List of ASes daemonised_ases

for

( ip , o b j e c t )

o b j e c t . r un n i ng _ da e m on within = this topology

and not
that are

in

G l o b a l s . ROUTERS . i t e m s ( )

if

object . route_reflector ] running E S 's W D

[ o b j e c t . as_number

for

( ip , o b j e c t ) ]

in

G l o b a l s . ROUTERS . i t e m s ( )

if\

o b j e c t . r un n i ng _ da e m on

if

l e n ( d a e m o n i s e d _ a s e s ) <=

continue
S t a t i s t i c s .D E O _ O N A M N C U T 1 0 0 / l e n ( G l o b a l s . ASES ) , Highest Detection , Lowest Detection for this attack type with

daemon_p = #A v e r a g e #t h i s

detection

deployment

level = [0 ,0 , float ( ' inf ' )]

FIXATED_DETECTION [ mode ] [ daemon_p ] x = 0 = []

lowest_undetected # attack each AS

running

an E S W D by

all

other

ASes

for

victim_as x+=1

in

daemonised_ases :

Simulator . clean_state () C o n f i g u r a t i o n . l o a d _ t o p o l o g y ( " c o n f i g / "+ f i l e n o ) # Choose a router that should announce things at the victim

for

victim_ip , r o u t e r _ o b j e c t

i f not o b j e c t . r un n i ng _ da e m on and not break

the victim router 5 to announce = G l o b a l s . TIME +

in

G l o b a l s . ASES [ v i c t i m _ a s ] . r o u t e r s . i t e m s ( ) : object . route_reflector :

Schedule

some

prefix

stime

a d d _ e v e n t ( s t i m e + 2 0 ,command , " new stime hit # = + = 20 [] give each = 2 attack 2

n e t

"+v i c t i m _ i p+" / 8

at

"+v i c t i m _ i p )

again

chances

to

be

captured + 5

by

daemons

periodic

CRA

flood

attack_length

Daemon . Daemon . ASSERTION_RATE

for

( attacker_ip , attacker_as )

in r o u t e r s : i f a t t a c k e r _ a s in h i t : continue e l s e : h i t . append ( a t t a c k e r _ a s ) i f a t t a c k e r _ a s == v i c t i m _ a s : continue

AS within the topology will attack this AS running an E S W D

# Each

if

mode = = "DIRECT" : S t a t i s t i c s . ATTACKS [ ( v i c t i m _ i p+" / 8 " , s t r ( a t t a c k e r _ a s ) ) ] a d d _ e v e n t ( s t i m e , command , " new = False

n e t

"+v i c t i m _ i p+" / 8

at

"+a t t a c k e r _ i p ) at "\

a d d _ e v e n t ( s t i m e+a t t a c k _ l e n g t h , command , " w i t h d r a w +a t t a c k e r _ i p )

"+v i c t i m _ i p+" / 8

if

mode = = "INDIRECT" : skip # if = False already connected then you its not an indirect attack

there

if

s t r ( attacker_as ) skip = True

in

Generator . as_peers [ s t r ( victim_as ) ] :

S t a t i s t i c s . ATTACKS [ ( v i c t i m _ i p+" / 8 " , s t r ( a t t a c k e r _ a s ) ) ] a d d _ e v e n t ( s t i m e , command , "mod " at

skip

n e t

"+v i c t i m _ i p+" / 8

"+ s t r ( v i c t i m _ a s )+\

"+a t t a c k e r _ i p ) "+v i c t i m _ i p+" / 8 at "\

a d d _ e v e n t ( s t i m e+a t t a c k _ l e n g t h , command , " w i t h d r a w +a t t a c k e r _ i p )

if

mode = = "DEAGGREGATION" : S t a t i s t i c s . ATTACKS [ ( v i c t i m _ i p+" / 8 " , s t r ( a t t a c k e r _ a s ) ) ] a d d _ e v e n t ( s t i m e , command , " new = False

n e t

"+v i c t i m _ i p+" / 1 6

at

"+a t t a c k e r _ i p ) at "\

a d d _ e v e n t ( s t i m e+a t t a c k _ l e n g t h , command , " w i t h d r a w +a t t a c k e r _ i p ) stime # Attacks + = attack_length now all + 5 scheaduled , run start this

"+v i c t i m _ i p+" / 1 6

have

been

simulator ' , l e n ( S t a t i s t i c s . ATTACKS) , \

print

' Starting

fixated

attack

' , mode , ' a t t a c k s

21

268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 # # If # #

' attacks

scheduled ' ' , i /10.0 ' , x , ' / ' , l e n ( daemonised_ases ) ' , seeded finish time ' , stime

print print print print

#

' P ( Daemon ) ' Victimised ' Seeded ' Expected the

Start

simulation

S i m u l a t o r . s t a r t ( F a l s e , stime , run ) # Simulation has = ended , now collect results regarding attack detection

total_attacks found_n =

l e n ( S t a t i s t i c s . ATTACKS)

l e n ( [ True

for

attack , found

in

S t a t i s t i c s . ATTACKS . i t e m s ( )

if

found

])

found_p # Sum

i n t ( found_n the

100/ t o t a l _ a t t a c k s )
rates undet his mode and deployment . later averaged + = found_p this mode and deployment ?

all

detection

FIXATED_DETECTION [ mode ] [ daemon_p ] [ 0 ] # is this the highest detection

under

if
#

found_p > FIXATED_DETECTION [ mode ] [ daemon_p ] [ 1 ] : FIXATED_DETECTION [ mode ] [ daemon_p ] [ 1 ] is this the lowest derection under this = found_p and deployment ?

mode

if

found_p < FIXATED_DETECTION [ mode ] [ daemon_p ] [ 2 ] : FIXATED_DETECTION [ mode ] [ daemon_p ] [ 2 ] lowest_undetected = [ attack = found_p

i f not
# Log this detection rate under

for
the

attack , found

in

S t a t i s t i c s . ATTACKS . i t e m s ( )

found ] appropiate AS tier the victim belonged to

if if if
Clean from

s t r ( victim_as )

in in in

G e n e r a t o r . T1 :

DETECTION_TIER_DIST [ ' T1 ' ] [ mode ] . a p p e n d ( found_p ) s t r ( victim_as ) G e n e r a t o r . T2 :

DETECTION_TIER_DIST [ ' T2 ' ] [ mode ] . a p p e n d ( found_p ) s t r ( victim_as ) G e n e r a t o r . T3 :

DETECTION_TIER_DIST [ ' T3 ' ] [ mode ] . a p p e n d ( found_p ) up the the stored results , calculate everages , highest and lowest are no diffrences

average /= f l o a t ( l e n ( daemonised_ases ) ) FIXATED_DETECTION [ mode ] [ daemon_p ] [ 0 ]

FIXATED_DETECTION [ mode ] [ daemon_p ] [ 0 ] FIXATED_DETECTION [ mode ] [ daemon_p ] [ 1 ] FIXATED_DETECTION [ mode ] [ daemon_p ] [ 2 ]

= FIXATED_DETECTION [ mode ] [ daemon_p ] [ 0 ] FIXATED_DETECTION [ mode ] [ daemon_p ] [ 2 ]

there

is

variance and

in

detection attacks 0: # use

rates ,

i . e .

attacks

were

un

detected ,

then

store

the

topology

detected !=

for

manual

review

if

len ( lowest_undetected ) In =

o p e n ( " c o n f i g / "+ f i l e n o )

raw

strings

for

windows

file

names config " , "w" )

Out =

o p e n ( " c o n f i g / f i x a t e d / "+mode+" / "+ s t r ( daemon_p)+ "

t o p o l o g y .

for

line

in

In :

Out . w r i t e ( l i n e ) Out . c l o s e ( ) Out = o p e n ( " c o n f i g / f i x a t e d / "+mode+" / "+ s t r ( daemon_p)+ "

f a i l i u r e

. config " ,

"w" )

for

ip , s o u r c e

in

lowest_undetected : : "+i p+" S o u r c e : "+s o u r c e+" \ n " )

Out . w r i t e ( " T a r g e t In . c l o s e ( ) Out . c l o s e ( )

732 733 734 735 736 737 738 739 740 741

def

draw ( )

. . . . . . . . . . . . . . . . . . . .

if

l e n (FIXATED_DETECTION) plot . figure (2) handles offset style = = , 0 [ ' ro , labels = []

!=

[]

'

, ' go

'

, ' bo

' ]
:

for

type

entry

in

FIXATED_DETECTION . i t e m s ( )

x , y = make ( e n t r y , 0 , o f f s e t ) xerr , yposerr = make ( e n t r y , 1 )

22

742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771

xerr , ynegerr s =

= make ( e n t r y , 2 )

s t y l e . pop ( ) = plot . plot (x , y , s ) y, y e r r =[ y n e g e r r , y p o s e r r ] , f m t=s )

line

plot . errorbar (x ,

h a n d l e s . append ( l i n e ) l a b e l s . append ( t y p e ) offset + = 1

p l o t . x l a b e l ( '% Daemons ' ) p l o t . y l a b e l ( '% plot . figlegend ( Attacks Detected ' ) right ' ) single target ")

t u p l e ( h a n d l e s ) , t u p l e ( l a b e l s ) , ' upper rate of attacks fixated on a

plot . t i t l e ( " Detection plot . figure (3) handles x = 1 , labels = []

[]

for

t i e r , entry colours =

in

DETECTION_TIER_DIST . i t e m s ( ) : ' cyan ' , ' yellow ' ]

[ ' magenta ' ,

for

type , v a l u e s y = dot

in

entry . items ( ) :

f l o a t ( sum ( v a l u e s ) ) / l e n ( v a l u e s ) = plot . scatter (x , y, c=c o l o u r s . pop ( ) )

if

type

not in

labels :

h a n d l e s . append ( d o t ) l a b e l s . append ( t y p e ) plot . annotate ( t i e r , x+=1 p l o t . ylim ( [ 0 , 1 0 1 ] ) p l o t . y l a b e l ( ' Average plot . figlegend ( plot . t i t l e ( " Tier . . . . . . . . . Detection %' ) right ' ) xy =(x , 2) , x y t e x t =(x , 2))

t u p l e ( h a n d l e s ) , t u p l e ( l a b e l s ) , ' upper detection ")

8.4 BGP.py
We have included this module fully, since it holds core code to our project, this module represents the BGP

algorithm and not the structures used by our BGP implementation

100% of module code
BGP :

Listed:
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

class

""" This is a class by description L{ R o u t e r } representing that BGP on on it a router to , as such it . it is this class

encapsulated encapsulates the router

class

calls that

simulate and of on IP

Furthermore BGP sessions

L{ BGP_Session } encapsulates

objects this

represent and on

simulates its peers

between

that

BGP

object is

@ivar @ivar

router :

L{ R o u t e r } L{map} session

object of all

this

BGP

running to

sessions :

L{ B G P _ S e ss i o n s }

the

address

of

the

router

at

other

end object of this routers BGP RIB

@ivar """

table :

L{BGP_Table}

def

__init__ ( s e l f , r o u t e r ) : """ constructor @param """ s e l f . router = router = {} # Sessions For handled the by this BGP object for : BGP the object router this BGP is running on

router

self . sessions s e l f . table

= BGP_Table ( )

# RIB

router

23

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 new_routes_count # Command all = 0 to recevive and process any BGP messages recevied ' ' ' ibgp

def

start_sessions ( s e l f ): """ Creates once This """ BGP the sessions same by for all valid stay peering up t i l l relationships its bought all , sessions by are are created of the peer .

and is

session the

will

down

either init

end

called

configuraton

module

once

routers

for

( peer_router_number , p e e r _ r o u t e r ) # # if to a session our already session exists then for do

in
not

s e l f . router . peers . items () specific up a peer or this

: peer does not want

this

accept

bring

session peer_router . accept_router ( s e l f . router ) :

if

peer_router_number

continue
= True

in

self . sessions

or not

if

p e e r _ r o u t e r . as_number = =

s e l f . r o u t e r . as_number

else
BGP

False

session # add

= BGP_Session ( s e l f . r o u t e r , p e e r _ r o u t e r , i b g p ) session to this BGP protocol = and to the peer target protocol

the

s e l f . s e s s i o n s [ peer_router_number ]

session

peer_router . accept_session ( s e l f . router , s e s s i o n ) ' ' ' s e l f . r o u t e r . l o g . a p p e n d ( "BGP session : "+ p e e r _ r o u t e r . number+" AS + " iBGP = " "+\ +s t r ( i b g p ) ) "+\ +s t r ( i b g p ) )

s t r ( p e e r _ r o u t e r . as_number ) p e e r _ r o u t e r . l o g . a p p e n d ( "BGP session :

"+ s e l f . r o u t e r . number+" AS + " iBGP = "

s t r ( s e l f . r o u t e r . as_number )

def

simulate ( s e l f ) : """ Method sending @return """ # If there = are changes to the RIB command all sessions to transmit them then clear them used all to command to this the of BGP RIB new protocol to run and a single simulation all step , this on consists Sessions of

changes :

and

reciving

processing

messages

sent

Integer

number

routes

learned

sessions

self . sessions > 0: , they dont : sent routing info , only listen

if

l e n ( s e l f . t a b l e . changes ) # Daemons run modified

BGP

i f not s e l f . r o u t e r . r un n in g _ da e mo n for i p in s e s s i o n s :
s e l f . t a b l e . delete_change ( )

s e s s i o n s [ i p ] . send ( s e l f . ro u te r , s e l f . t a b l e )

sessions :

for

ip

in

sessions =

count

s e s s i o n s [ ip ] . r e c e i v e ( s e l f . router , s e l f . table ) count

new_routes_count + =

return class

new_routes_count

BGP_Session :

""" BGP whom Session have class object , this it object represents sending a BGP session running between on bother two routers who

sucessfully session

peered .

handles

and

reciving

messages

routers

started @ivar @ivar @ivar @ivar @ivar """

this

peer_a : peer_b :

L{ R o u t e r } L{ R o u t e r }

at at

end end

A B

of of for for

the the

link link at at end end A B of of the the link link

peer_a_que : peer_b_que : ibgp :

Queue ( L{ l i s t } ) Queue ( L{ l i s t } ) if this

router router is an

indicator

session

iBGP

session

def

__init__ ( s e l f , p e e r _ a , peer_b , i b g p _ p e e r ) : s e l f . peer_a = peer_a

24

91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149

s e l f . peer_b

peer_b = = [] []

s e l f . peer_a_que s e l f . peer_b_que s e l f . ibgp =

ibgp_peer

def

send ( s e l f , sender , s e n d e r s _ t a b l e ) : """ Called UPDATE them in when changes to to the RIB other at the of one end of are detected , it and makes places

messages the ends :

notify

end

link

these

changes

queue L{ R o u t e r } : object of the router of sending the changes sending changes

@param @param """

sender

senders_table

L{BGP_Table } (BGP RIB )

router

messages

= =

[] [] out what side of in s e n d e r . number = = s e l f . p e e r _ a . number the link the reciver is on so we know who is reciving and

withdrawn # we # the must

figure to

queue =

put

the

messages

target_que reciver =

s e l f . peer_b_que

s e l f . peer_b

if

if

s e n d e r . number = =

s e l f . p e e r _ a . number

else

else

s e l f . peer_a_que

s e l f . peer_a

# For # for

every that

prefix prefix

that or

has

changed if if

in it

our is

table no

send in

all our

the table

new / c h a n g e d

routes

heard

withdraw

longer

for

prefix #

in

senders_table . changes : does not exist an ym o re than this : flag was to indicate a complete withdrawal

prefix

i f not

s e n d e r s _ t a b l e . has_entry ( p r e f i x )

withdrawn . append ( p r e f i x )

continue
entry = senders_table . get ( p r e f i x ) to send all the changed routes : a n ym or e than this entry flag is to indicate a route under the changed prefix # Attempt

for

route_number # # if this

in

entry . changes does not exist

route

withdrawal

( previous

best

route ) :

if

route_number

not in

entry . routes

withdrawn . append ( p r e f i x )

continue
route # if = we e n t r y . g e t _ r o u t e ( route_number ) are sending to a classed != link , only \ G l o b a l s . POLICIES [ r o u t e [ CONFEDERATION_LOC ] ] : send route if our policy permits

if

and s e n d e r . p e e r _ c l a s s [ r e c i v e r . number ] in continue

r o u t e [ CONFEDERATION_LOC ] None transmit this prefix = = if we heard r o u t e [H A D F O _ O E R _ R M L C] transmit routes

# Dont

it

from :

the

router

were

sending

to

now

if if

r e c i v e r . number from ibgp over

continue
ibgp except if the sender is a RR

# Dont

heard

r o u t e [H A D F O _ B P L C] E R _ R M I G _ O

and

s e l f . ibgp

and not

sender . route_reflector :

continue

origin

r o u t e [ ORIGIN_LOC ]

i f not
#

s e l f . ibgp : Sending to iBGP , attach your ASN , M D E , clear attributes transitive over

# iBGP as_path

only = = s t r ( s e n d e r . as_number)+ ' s e n d e r . number = s e n d e r . as_number '+r o u t e [AS_PATH_LOC]

next_hop

next_hop_as med =

s e l f . get_med ( p r e f i x , s e n d e r , r e c i v e r ) = 0 = None 0

local_pref igp_dist =

confederation

else :
# If were sending over iBGP then preserve attributes , save the iBGP metric

25

150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 # if no # # if

that

should = =

be

changed

as_path

r o u t e [AS_PATH_LOC] r o u t e [N X _ O _ O E T H P L C] = r o u t e [N X _ O _ S L C] E T H P A _ O

next_hop

next_hop_as med =

r o u t e [M D L C] E _ O = r o u t e [ LOCAL_PREF_LOC ] + s e n d e r . p e e r _ m e t r i c [ r e c i v e r . number ]

local_pref igp_dist =

r o u t e [ IGP_DIST_LOC ] =

confederation

r o u t e [ CONFEDERATION_LOC ]

added_flag # add

False to nlri of a previously created message with same route attributes

prefix

for

message

if

in

messages :

m e s s a g e . a c c e p t _ p r e f i x ( p r e f i x , o r i g i n , a s _ p a t h , next_hop , \ next_hop_as , med , l o c a l _ p r e f , i g p _ d i s t , c o n f e d e r a t i o n ) : added_flag = True

break
prefix could not be added to any message then add it to a new one with the prefix ' s route : attributes

i f not

added_flag

m e s s a g e s . a p p e n d ( U p d a t e ( p r e f i x , o r i g i n , a s _ p a t h , next_hop , next_hop_as , \ med , l o c a l _ p r e f , i g p _ d i s t , c o n f e d e r a t i o n ) ) messages exist = = 0 we create a dummy message > 0: to hold the withdrawals

if

l e n ( messages ) path =

and
=

l e n ( withdrawn )

s t r ( s e n d e r . as_number ) : path ' '

if if for del def

s e l f . ibgp

m e s s a g e s . a p p e n d ( U p d a t e ( ' ' , ' ' , p a t h , ' ' , ' ' , ' ' , ' ' , ' ' , None ) ) # Choose any message > 0 to to : put any withdrawals we have = in them

l e n ( withdrawn ) all

c h o i c e ( m e s s a g e s ) . withdrawn queue of the receiver at

withdrawn other end of the session

# Add

messages

the :

the

message

in

messages

t a r g e t _ q u e . append ( m e s s a g e )

messages [ : ]

receive ( self , reciver , reciver_table ): """ Used from to the receive BGP messages via this BGP session on one end , m e s s a g e s are processed

receivers :

queue L{ R o u t e r } : object of the router to reciving update on this the session BGP updates

@param @param """

receiver

receiver_table

L{BGP_Table } (BGP RIB )

with

received

# # W E COULD # determine =

just what

access queue

the

RIB

though to the

the

router end

object

but

that

l o n g ( r o u t e r . bgp . t a b l e )

belongs

reciving

input_que sender =

s e l f . peer_a_que

s e l f . peer_b

if

if

r e c i v e r . number = =

s e l f . p e e r _ a . number

r e c i v e r . number = =

s e l f . p e e r _ a . number

else

else

s e l f . peer_b_que

s e l f . peer_a

new_routes_count # Process each

message input_que : s e l f . process_update_message ( message , r e c i v e r , s e n d e r , r e c i v e r _ t a b l e )

for

message

in

new_routes_count + =

del i n p u t _ q u e [ : ] return n e w _ r o u t e s _ c o u n t def

process_update_message ( s e l f , message , r e c i v e r , s e n d e r , r e c i v e r _ t a b l e ) : """ Process changes @param @param @param an to update the message that has been read from route the receivers and queue , policy makes based appropiate routing

recivers : : : Update

BGP RIB message

based

on BGP

selection

message reciver sender

L{ U p d a t e } for for the the reciving end that end sent of the session message

L{ R o u t e r } L{ R o u t e r }

object object

this

26

209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267

@param """ # Dont

reciver_table

L{BGP_Table } (BGP RIB )

to

update

with

this

message

consider

routes

that

have

your

ASN

in

them : on

if
#

s t r ( r e c i v e r . as_number ) Modify = the M D E attribute

in

m e s s a g e . as_path . s p l i t ( ) the message based

return
the

0 filters

within

receivers

message # Speed

s e l f . a p p l y _ m e d _ f i l t e r ( message , r e c i v e r )

Mods = = s e l f . get_local_pref r e c i v e r _ t a b l e . has_entry prefixes : :

get_local_pref table_has_entry # Handle all

withdrawn

for

prefix

if

in

message . withdrawn

table_has_entry ( p r e f i x ) entry =

reciver_table . get ( p r e f i x ) = None all routes ( can under only be this one withdrawn due to prefix heard replace from in the sender of

remove_id # Remove # the

message

implicit

BGP_Table_Entry )

for

id , r o u t e

if

in

entry . routes . items ( ) : = = s e n d e r . number :

r o u t e [H A D F O _ O E R _ R M L C]

del

entry . routes [ id ] = id

remove_id

if

break
len ( entry . routes ) # Run # # then knock out > 0 : to see who if is the is our current changes best as winner to after the withdrawl will algorithim the a table change is to if not

command be a

check

there was

this

entry

, there

definately send if

remove_id found but

route , it is assumed withdrawn

# on

route

marked :

changed

if else
#

e n t r y . best_route_number = = remove_id

e n t r y . c h a n g e s . append ( remove_id )

s e l f . knockout ( e n t r y ) r e c i v e r _ t a b l e . check_change ( p r e f i x ) : alternatively just found tell and if the no routes are left then remove has the prefix , on altogether if the prefix is

# and # not

table as

that

the

prefix it is

changed as

send

marked

changed

assumed

withdrawn

del

reciver_table . entrys [ prefix ]

r e c i v e r _ t a b l e . c h a n g e s . append ( p r e f i x )

Handle

all

announced

prefixes :

in

the

Update

message

for

prefix # apply

in

message . n l r i pref =

local

filters

and

discover

the

local

pref

value

for

this

route

prefix_local_pref

g e t _ l o c a l _ p r e f ( message , p r e f i x , r e c i v e r ) : r e c i v e r _ t a b l e . add ( BGP_Table_Entry ( p r e f i x ) ) M D E THE MISTAK EARLY ON A E

i f not
entry # # the =

table_has_entry ( p r e f i x ) IS C M U I Y O M NT

# CONFEDERATION

our

TO LONG TO C A G H N E

reciver_table . get ( p r e f i x ) tag use is what ibgp peer tag specified , of the if not an ibgp peer or

confederation , then

unspecified =

the

confederation

peering

relationship != None ) \

confed

message . c o n f e d e r a t i o n

else
# add # this previous

if

( s e l f . ibgp

and
, the

message . c o n f e d e r a t i o n

r e c i v e r . p e e r _ c l a s s [ s e n d e r . number ] as a new route for the prefix of or the route will implicitly replace

route route

though

internal

operation

BGP

table

e n t r y . a d d _ r o u t e ( m e s s a g e . o r i g i n , m e s s a g e . a s _ p a t h , m e s s a g e . next_hop , m e s s a g e . next_hop_as , \ m e s s a g e . med , p r e f i x _ l o c a l _ p r e f , s e n d e r . number , s e l f . i b g p , c o n f e d , \ message . i g p _ d i s t ) # Run knock out algorithim to see who is the current winner after this new announcment

s e l f . knockout ( en t r y ) r e c i v e r _ t a b l e . check_change ( p r e f i x )

return def

l e n ( message . n l r i )

l e n ( message . withdrawn )

knockout ( s e l f , e n tr y ) : """

27

268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326

Runs route of

Knock the

out entry of

algorithim holds for

on the so

RIB

prefix , be the

entry best out

that route

identifies is then

the

best in the list

prefix could

marked

changes

that entry :

entry

it

sent of the

@param """

param

L{ BGP_Table_Entry }

table

to

run

the

K.O

algo

on

route_numbers get_route pop = =

copy ( e n t r y . r o u t e s . k e y s ( ) )

entry . get_route

r o u t e _ n u m b e r s . pop l e n ( route_numbers ) > 1 :

while

""" Knock out algorithim the that continually the compares with first two elements of the route_numbers to there values are 1

l i s t , to retrived item """ route_a

compare and BGP

elements

routes

route is

numbers

corrosponding breaks when

route

selection

comparision

applied .

loop

route_number

has

( Winner )

g e t _ r o u t e ( route_numbers [ 0 ] ) = l e n ( r o u t e _ a [AS_PATH_LOC ] . s p l i t ( ) )

route_a_as_count route_b =

g e t _ r o u t e ( route_numbers [ 1 ] ) = l e n ( r o u t e _ b [AS_PATH_LOC ] . s p l i t ( ) )

route_b_as_count

Highest

LOCAL PREF != r o u t e _ b [ LOCAL_PREF_LOC ] : < r o u t e _ b [ LOCAL_PREF_LOC ] : pop ( 0 )

if

r o u t e _ a [ LOCAL_PREF_LOC ]

i f r o u t e _ a [ LOCAL_PREF_LOC ] e l s e : pop ( 1 )
shortest AS PATH != >

# Then

elif

route_a_as_count

route_b_as_count route_b_as_count

: : pop ( 0 )

i f route_a_as_count e l s e : pop ( 1 )
Lowest M D E r o u t e _ a [M D L C] E _ O

# Then

elif

!=

None

and

r o u t e _ b [M D L C] E _ O

!=

None

r o u t e _ a [N X _ O _ S L C] E T H P A _ O r o u t e _ a [M D L C] E _ O != >

= = r o u t e _ b [N X _ O _ S L C] E T H P A _ O : pop ( 0 )

and and

\ \

r o u t e _ b [M D L C] E _ O :

i f r o u t e _ a [MED_LOC] e l s e : pop ( 1 )
# eBGP over iBGP

r o u t e _ b [M D L C] E _ O

elif

r o u t e _ a [H A D F O _ B P L C] E R _ R M I G _ O

!= :

r o u t e _ b [H A D F O _ B P L C ] : E R _ R M I G _ O pop ( 0 )

i f r o u t e _ a [HEARD_FROM_IBGP_LOC] e l s e : pop ( 1 )
IGP metric != > r o u t e _ a [ IGP_DIST_LOC ]

Lowest

elif

r o u t e _ b [ IGP_DIST_LOC ] r o u t e _ b [ IGP_DIST_LOC ]

: : pop ( 0 )

i f r o u t e _ a [ IGP_DIST_LOC ] e l s e : pop ( 1 )
Breaker

Tie

else : if

i n t ( ' ' . j o i n ( r o u t e _ a [N X _ O _ O ] . r s p l i t ( ' . ' ) ) ) E T H P L C

>

\ pop ( 0 )

i n t ( ' ' . j o i n ( r o u t e _ b [N X _ O _ O ] . r s p l i t ( ' . ' ) ) ) : E T H P L C

else
# # if the

pop ( 1 ) = a pop ( ) diffrent route to the previous best route then add it to

best_route_number winner entry is

prefix

change != e n t r y . best_route_number :

if

best_route_number

if

best_route_number

not in
=

entry . changes

e n t r y . c h a n g e s . append ( best_route_number )

e n t r y . best_route_number

best_route_number

def

g e t _ l o c a l _ p r e f ( s e l f , message , p r e f i x , r e c i v e r ) : """ Used to return message the : LOCAL PREF

value

for

prefix

within

recived

BGP

update

message

@param

BGP L{ U p d a t e }

message

28

327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370

@param @param """

prefix reciver

: :

specific the

prefix

within of

the the

message router reciving / calculating local

L{ R o u t e r }

object

p r e f

if

s e l f . ibgp

elif elif elif elif

# #

return return return return return

so i

message . l o c a l _ p r e f

( p r e f i x , m e s s a g e . next_hop )

in

reciver . local_pref_prefix_router_filter :

r e c i v e r . l o c a l _ p r e f _ p r e f i x _ r o u t e r _ f i l t e r [ ( p r e f i x , m e s s a g e . next_hop ) ]

( p r e f i x , m e s s a g e . next_hop_as )

in

reciver . local_pref_prefix_as_filter

r e c i v e r . l o c a l _ p r e f _ p r e f i x _ a s _ f i l t e r [ ( p r e f i x , m e s s a g e . next_hop_as ) ]

m e s s a g e . next_hop

in

reciver . local_pref_router_filter :

r e c i v e r . l o c a l _ p r e f _ r o u t e r _ f i l t e r [ m e s s a g e . next_hop ]

m e s s a g e . next_hop_as

in

reciver . local_pref_as_filter

r e c i v e r . l o c a l _ p r e f _ a s _ f i l t e r [ m e s s a g e . next_hop_as ] dont confuse myself , i could is just return except message . l o c a l _ p r e f if were sending over to the same effect ,

just

becuase 0

when

sending

local_pref

cleared

IBGP

return def

get_med ( s e l f , p r e f i x , s e n d e r , r e c i v e r ) : """ Used to return prefix reciver sender the : : : M D E value for to a prefix we the the the are M D E about for that that will is recieve this M D E to send to <s e n d e r >

@param @param @param """

the the the

prefix

calculate object object of of

L{ R o u t e r } L{ R o u t e r }

router router

sending

this

message

if

( p r e f i x , r e c i v e r . number )

elif elif elif

return return return

in

sender . MED_prefix_router_filter :

s e n d e r . M E D _ p r e f i x _ r o u t e r _ f i l t e r [ ( p r e f i x , r e c i v e r . number ) ]

( p r e f i x , r e c i v e r . as_number )

in

s e n d e r . MED_prefix_as_filter

s e n d e r . M E D _ p r e f i x _ a s _ f i l t e r [ ( p r e f i x , r e c i v e r . as_number ) ]

r e c i v e r . number

in

s e n d e r . MED_router_filter :

s e n d e r . M E D _ r o u t e r _ f i l t e r [ r e c i v e r . number ]

r e c i v e r . as_number in s e n d e r . M E D _ a s _ f i l t e r : return s e n d e r . M E D _ a s _ f i l t e r [ r e c i v e r . as_number ] return None

def

a p p l y _ m e d _ f i l t e r ( s e l f , message , r e c i v e r ) : """ method @param @param """ used to apply : : BGP the M D E filters to recived BGP L{ U p d a t e } messages

message reciver

Update Router

message object of the router r e c i v i n g / applying filter

if

r e c i v e r . ignore_all_med

( m e s s a g e . next_hop

in

or

( m e s s a g e . next_hop_as :

in

r e c i v e r . ignore_as_med )

or

r e c i v e r . ignore_router_med )

m e s s a g e . med = None

return

message

8.5 BGP_Structures.py
To complement the full listing of our BGP implementation code (BGP.py) we will also fully list the support structures used by BGP.py, together BGP.py and BGP_Structures.py describe implementation.

fully

our BGP

Listed:
7 8 9 #

100% of module code

of attributes 0 1 within a route tuple

Indexes

ORIGIN_LOC =

AS_PATH_LOC =

29

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

N X _ O _ O E T H P L C =

2 3

N X _ O _ S L C = E T H P A _ O M D L C = E _ O 4 5 6

LOCAL_PREF_LOC = H A D F O _ O E R _ R M L C =

H A D F O _B P L C = E R _ R M I G _ O CONFEDERATION_LOC = IGP_DIST_LOC = 9 8

class

Update :

""" Update """ object representing a BGP update message structure

def

__init__ ( s e l f , p r e f i x , o r i g i n , a s _ p a t h , next_hop , next_hop_as , med , l o c a l _ p r e f , igp_dist , c o n f e d e r a t i o n ) : """ method be """ self . origin = = origin as_path next_hop = next_hop_as used to to it initialise along with a BGP all update its messages , to initialise requierd a BGP message a prefix must

passed

attributes

that

are

for

an UPDATE

message

s e l f . as_path

s e l f . next_hop

s e l f . next_hop_as s e l f . med = med s e l f . local_pref self . nlri = [] =

local_pref

s e l f . withdrawn s e l f . igp_dist

[] igp_dist = confederation

s e l f . confederation

if def

prefix

!=

' '

s e l f . n l r i . append ( p r e f i x )

a c c e p t _ p r e f i x ( s e l f , p r e f i x , o r i g i n , a s _ p a t h , next_hop , next_hop_as , med , l o c a l _ p r e f , igp_dist , c o n f e d e r a t i o n ) : """ method same nlri """ used to accept a as p r e f i x / route the prefix into that this messages nlri , i . e . if the we prefix add it has to the

route / a tt r i bu te s

initialised

this

message

then

the

if

self . origin

= =

origin

\ \ \ \

and and and and and and and

s e l f . as_path = = as_path

s e l f . next_hop = = next_hop

s e l f . next_hop_as = = next_hop_as s e l f . med = = med s e l f . local_pref s e l f . igp_dist \ = = local_pref \ \

= =

igp_dist = =

s e l f . confederation

confederation :

s e l f . n l r i . append ( p r e f i x )

return T r u e return F a l s e class

BGP_Table :

""" Represents @ivar @ivar """ the RIB on a of router running to BGP L{ BGP_Table_Entry } ' s changes within them

entrys : changes :

L{map}

prefixes of

there that

L{ l i s t }

prefixes

have

def

__init__ ( s e l f ) : s e l f . entrys s e l f . changes = = {} []

30

69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 @ivar @ivar @ivar route_count best_route_number changes : : :

def

items ( s e l f ) : """ returns """ items for entrys held within the RIB

return def

s e l f . entrys . items ()

add ( s e l f , e n t r y ) : """ Adds an entry entry : to the RIB object representing an entry for a prefix

@param """

L{ BGP_Table_Entry }

s e l f . entrys [ entry . p r e f i x ]

entry

def

get ( s e l f , p r e f i x ) : """ Returns @param @return """ the entry : for a given to prefix entry for a for specified prefix

prefix :

prefix

retrive entry }

L{ BGP_Table_Entry

return def

s e l f . entrys [ prefix ]

has_entry ( s e l f , p r e f i x ) : """ returns @param @return """ the status : of an to entrys check entry existance entrys exists , for a given for prefix

prefix : True

prefix if

existance False

prefix

otherwise

i f p r e f i x in return F a l s e def

s e l f . entrys

return

True

check_change ( s e l f , p r e f i x ) : """ method @param """ that checks the if the prefix to entry for a prefix for has any changed routes within it

prefix :

prefix

check

change

state

if def

l e n ( s e l f . entrys [ p r e f i x ] . changes ) s e l f . c h a n g e s . append ( p r e f i x )

!=

and

prefix

not in

s e l f . changes

delete_change ( s e l f ) : """ method """ that clears all changes from this table

for

prefix # # if it

in

s e l f . changes : change exists flag and was we not must for the complete list of removal changed of a prefix then

this s t i l l

clear

its

routes

if class del

prefix

del

in

s e l f . entrys :

s e l f . entrys [ p r e f i x ] . changes [ : ]

s e l f . changes [ : ]

BGP_Table_Entry :

""" Represents @ivar @ivar @ivar a structure for : : : an the entry prefix of of for a prefix BGP ids in the BGP RIB is for for is this prefix from to the id of the L{BGP_Table}

prefix routes heard_from_to_id

this route the ip

table to

entry

L{map} L{map} route the the a

routes a

heard route

addresses

heard

heard of id all routes of the currently best route ids in for the table entry

number route of

this

prefix

list

the

route

that

have

changed

31

128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 s e l f . r o u t e s [ route_id ] """ Adds a heard : route id self . prefix s e l f . routes = = prefix {} """

( new

winner

or

implict

replace

or

withdrawn )

def

__init__ ( s e l f , p r e f i x ) :

s e l f . heard_from_to_id s e l f . route_count = 0

{}

s e l f . best_route_number s e l f . changes = []

= None

def

a d d _ r o u t e ( s e l f , o r i g i n , a s _ p a t h , next_hop , next_hop_as , med , l o c a l _ p r e f , h e a r d _ f r o m , \ heard_from_ibgp , c o n f e d e r a t i o n , i g p _ d i s t ) :

for of

this the

prefix

to

this

entry

@return """ route_id

route

added

route

s e l f . route_count

if

heard_from route_id

in

s e l f . heard_from_to_id :

s e l f . heard_from_to_id [ heard_from ] route_id only : it on if its our best route

if else
#

s e l f . best_route_number = = #I m p l i c i t l y replaced ,

but

send

s e l f . c h a n g e s . append ( r o u t e _ i d ) : Just simply a new route = route_id

s e l f . heard_from_to_id [ heard_from ] s e l f . route_count +=1

( o r i g i n , a s _ p a t h , next_hop , next_hop_as , med , l o c a l _ p r e f , heard_from , heard_from_ibgp , c o n f e d e r a t i o n , i g p _ d i s t )

def

return
""" returns @param @return """

route_id

get_route ( s e l f , route_id ) :

the

route :

tuple the id

for of

specified route route we

route have to return

route_id : the

the

L{ t u p l e }

holding

information

return def

s e l f . r o u t e s [ route_id ]

get_best_route ( s e l f ) : """ returns @return """ the : route tuple for the best route route for this entry

the

L{ t u p l e }

holding

information

return

s e l f . g e t _ r o u t e ( s e l f . best_route_number )

8.6 Daemon.py
This module is the controller for an EWSD within our simulator, from this module we have included

some

of its methods that describe some key operations it carries out. We have omitted half of this module, the omitted code consists of the P2P_session implementation/class, methods that handle an EWSDs periodic, and many helper methods e.g. ood, deaggregation_check.

Listed:

45% of module code

32

Some of the methods that handle session processing

70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

def

accept_session ( s e l f , session ) : """ Used if to accept daemon peer : Session the daemon session proposed by the other daemon connection is attempts to from accept other , or daemons if the , accepts is the session for a

the

preconfigured

daemon

waiting

random @param """ # since

the

session

is

proposed

to

us

then

we :

are

at

end

of

the

session

if

s e s s i o n . enda [ 0 ]

in

s e l f . configured_peers

s e l f . p e e r _ s e s s i o n s [ s e s s i o n . enda [ 0 ] . i p ]

session

s e l f . c o n f i g u r e d _ p e e r s . remove ( s e s s i o n . enda [ 0 ] )

elif

return

True : = session

s e l f . awaiting_random_peer

s e l f . p e e r _ s e s s i o n s [ s e s s i o n . enda [ 0 ] . i p ] s e l f . awaiting_random_peer = False

return

return
False

True

Method that veries received messages

114 115 116 117 118 119 120 121 122 123 124 125 126

def

new_sessions_handler ( s e l f ) : """ method these used peers to try and have bring been a peering sessions manually with or by configured accepting peers an RPR .

could

configured over IP

communications i . e . """ simulated

here

happen

through

direct

communication

through

daemon

objects

for

peer

in if

s e l f . configured_peers =

session

P2P_Session ( s e l f , p e e r )

peer . accept_session ( s e s s i o n ) : s e l f . peer_sessions [ peer . ip ] #p r i n t ' SESSION ' , = session = = ' , s e l f . ip

peer . ip , '

s e l f . c o n f i g u r e d _ p e e r s . remove ( p e e r )

160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183

def

i s _ v a l i d ( s e l f , message ) : """ Used to 1. 2. check if if key the the that a received of is or the of with be a message is is valid as , applies daemon the several checks which are as follows

source message it

message PKE the key type

the

this

represents message for the

then

invalid with the it public

then

ensure

that

verifies AS number

within it

public change ) be

key ( i f

any )

held

within

( because 3. The if 4. @param @return """ source , type = The : :

may

messages no key

signature or

can

verified then time

using

the is

key

we

have

for

the

AS

that

sent

it

held

cannot is

verify +

message

invalid otherwise invalid

message

time to

stamp

the

stamp

window

L{ M e s s a g e } True if

validate message is valid , False otherwise

the

m e s s a g e . g e t S t a t e ( "SOURCE_AS" )

m e s s a g e . g e t S t a t e ( "TYPE" )

if

source

= =

s e l f . advertised_as

: s e l f . c r y p t e r . public_key :

if

type

= = PKE_TYPE #p r i n t

and

m e s s a g e . g e t S t a t e ( "PUBLIC_KEY" ) ! =

' Hijack ' ' Public Key ' , m e s s a g e . g e t S t a t e ( "CONTACT_IP" ) , ' ')

s e l f . a d d _ t o _ l o g (KEY_HIJACK,

elif

return
type # Must

False : either internal public key , or held private key ( key \ change )

= = PKE_TYPE verify with

i f not

( s e l f . c r y p t e r . v e r i f y ( m e s s a g e , m e s s a g e . g e t S t a t e ( "PUBLIC_KEY" ) )

33

184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 #I f

or s e l f . c r y p t e r . v e r i f y ( m e s s a g e ) ) : return F a l s e
# Timestamp # should be window does not apply changed to , PKE when messages , changed whole then point is that will they not veirfy replayed until old PKE ' s

return
we cant

True verify the message using the crypter component then message is invalid

i f not s e l f . c r y p t e r . v e r i f y ( m e s s a g e ) : print ' I n v a l i d M e s s a g e ' , m e s s a g e . g e t S t a t e ( "TYPE" ) return F a l s e

# as stated message time stamp must = +

TM _ T M _ I D W I E S A P WN O , SEE the process_message method

# OBSELETE, time_window

REPLAY ATTACKS ARE NO DELT WITH USING SEQNO = G l o b a l s . TIME

m e s s a g e . g e t S t a t e ( "TIMESTAMP" )

return F a l s e return T r u e

if

a b s ( time_window )

> T M _ T M _ I D W: I E S A P WN O

Methods that process some of the received messages

199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239

def

p r o c e s s _ c r a ( s e l f , s o u r c e _ s e s s i o n , message ) : """ Bounces had and received CRA messages onto in it the the graph graph processor then on this the daemon , on if to the all CRA message ,

paths

accepted / l i f e the message

extended to the see if

flood

message

peers

inspect

uncovers

attacks was heard from

@param @param """

source_session : message : the

session

this

message

actual

L{ M e s s a g e }

heard

if

s e l f . g r a p h . commit ( m e s s a g e , s o u r c e _ s e s s i o n ) s e l f . flood_message ( message , s e l f . a l e r t _ h a n d l e r ( message )

source_session )

def

process_pke ( s e l f , s o u r c e _ s e s s i o n , message ) : """ Used the if to handle key is validated within new or it PKE into a messages our , handling for then the the AS PKE entails in an the attempt PKE . to assert

public this key

store

advertised the message from

causes the

conflict this

flood was

@param @param """ signal

source_session : message : the

session

message

heard

actual

L{ M e s s a g e }

heard

s e l f . c r y p t e r . commit ( m e s s a g e ) = = KEY_COMMITED_SIGNAL

if

signal

if

or

signal :

= = KEY_CONFLICT_SIGNAL :

signal True

= = KEY_CONFLICT_SIGNAL

s e l f . f l o o d _ m e s s a g e ( m e s s a g e , s o u r c e _ s e s s i o n , True )

def

p r o c e s s _ r p r ( s e l f , s o u r c e _ s e s s i o n , message ) : """ When we receive has less a RPR than < message 5 100 hops then left , we accept it if we have space for on to peering a and the session

message if it

otherwise

bounce

the

message

random

peer

has

0 >

hops

left . session this message was heard from

@param @param """ hops c_ip = =

source_session : message : the

the

actual

L{ M e s s a g e }

heard

m e s s a g e . g e t S t a t e ( "HOPS" ) m e s s a g e . g e t S t a t e ( "CONTACT_IP" ) < 5

if

hops c_ip

in

and

len ( s e l f . peer_sessions ) :

<

s e l f . maximum_peerings

and not \

s e l f . peer_sessions

34

240 241 242 243 244 245 246 247 248 249

communication pulling up

will the

now

happen

over for

IP

directly ip in

, the

so

we

simualte message

that storing that in

# by #

daemon for

object

the

RPR

and

configured

peers =

later

connection

source_daemon

G l o b a l s . ROUTERS [ c _ i p ] . daemon

s e l f . c o n f i g u r e d _ p e e r s . append ( source_daemon )

elif

return
hops != 0

and

hops

<

64

m e s s a g e . s e t S t a t e ( "HOPS" , h o p s session =

1)

choice ( s e l f . peer_sessions . values ())

s e s s i o n . transmit_message ( s e l f . ip , message )

Method that scans valid CRA messages for attacks

250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 # Check every path for prefix hijacks

def

a l e r t _ h a n d l e r ( s e l f , message ) : """ Processes daemon on its a recived , it CRA message all that caused , path ) router this a state pairs change for to in the attempts and threats

Graph

checks AS

( prefix AS its

hijack

represented message :

i . e .

the

belongs daemon

@param """ payload #

L{ M e s s a g e }

received

by

m e s s a g e . g e t S t a t e ( "P AY LO AD" ) from the fast the AS it BGP is table of the on router this daemon ' ' is running on all the prefixes

Identify by

# owned # map local

running

i . e .

AS PATH =

for = {}

lookup

for

entry

for

in

s e l f . bgp_table . e n t r y s . v a l u e s ( ) :

route

if

in

entry . routes . values ( ) : = = "" = 0 :

r o u t e [AS_PATH_LOC]

l o c a l [ entry . p r e f i x ]

break for
prefix

if

in
If

payload

prefix # #

in
this

local : is a prefix explicitly owned by the daemons represented AS the

look

for

prefix

hijacks

for

path

in
=

payload [ p r e f i x ] : l e n ( path )

length

if

path [ l e n g t h

1]

!=

s t r ( s e l f . advertised_as ) : i . e . path shows diffrent source

# DIRECT PREFIX HIJACK cause = path [ l e n g t h

1]
prefix , ' System '+c a u s e , path )

s e l f . a d d _ t o _ l o g (DIRECT_PREFIX_HIJACK,

if elif

( prefix , cause )

in

S t a t i s t i c s . ATTACKS : = True

S t a t i s t i c s . ATTACKS [ ( p r e f i x , c a u s e ) ] length > 1

and

path [ l e n g t h

2 ] not in
path

s e l f . as_peers : fake connection to to the real source

# INDIRECT PREFIX HIJACK cause = path [ l e n g t h

i . e .

shows

2]
prefix , ' System '+c a u s e , path ) S t a t i s t i c s . ATTACKS : = True

s e l f . a d d _ t o _ l o g ( INDIRECT_PREFIX_HIJACK ,

if else : if

( prefix , cause )

in

S t a t i s t i c s . ATTACKS [ ( p r e f i x , c a u s e ) ]

prefix #

in

s e l f . graph . p r e f i x _ p a t h s : may not = be in the map if triples not in map used alone

Prefix

lowest , highest

s e l f . graph . g e t _ p r e f i x _ t r u s t _ m e t r i c s ( p r e f i x )

if

highest [ 0 ] lowest [ 0 ]

> MINIMUM_TRUST < 0.5

and
is

lowest [ 1 ]

in
only

payload [ p r e f i x ]

and

highest
i . e .

[0]: not the path for the prefix

# UNTRUSTED ROUTE

this

35

296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 # Check # # If

# and

it

has

the

worst

triple

score = True Triple "+\

S t a t i s t i c s .THIRD_PARTY_ATTACKS[ p r e f i x ] s e l f . a d d _ t o _ l o g (UNTRUSTED_PATH_SEEN, str ( lowest [ 2 ] ) , this for prefix is not explicitly attacks

prefix , str ( lowest [1])+ "

lowest [ 1 ] ) owned by the daemons represented AS then

look

DEAGGREGATION =

check_format

p r e f i x . r s p l i t ( "/" )

for

local_prefix

if

in

local : : daemons AS

s e l f . deaggregate_check ( l o c a l _ p r e f i x . r s p l i t ( "/" ) , check_format ) # if this the prefix daemon is was a deaggregation not told it of any be prefix owned by then

the

# and

could

deaggregated

warn

if

local_prefix

break
= =

in

s e l f . deaggregate_prefixes :

path cause

payload [ p r e f i x ] [ 0 ] path [ l e n ( path )

1]

if

( local_prefix , cause )

in

S t a t i s t i c s . ATTACKS : = True p r e f i x , path )

S t a t i s t i c s . ATTACKS [ ( l o c a l _ p r e f i x , c a u s e ) ] s e l f . a d d _ t o _ l o g (DEAGGREGATION_HIJACK,

local_prefix ,

break
every path for policy violations

for

path

if

in if

payload [ p r e f i x ] :

s t r ( s e l f . advertised_as ) index =

in

path :

l i s t ( path ) . i n d e x ( s t r ( s e l f . a d v e r t i s e d _ a s ) ) < l e n ( path )

index t f = = f

path [ index

1 and 1]

index

>

0:

p a t h [ i n d e x +1]

if

in s e l f . a s _ p e e r s and t in s e l f . a s _ p e e r s : i f s e l f . a s _ p e e r s [ t ] in G l o b a l s . POLICIES [ s e l f
s e l f . a d d _ t o _ l o g (POLICY_VIOLATION,

. as_peers [ f ] ] : ' System '+t , path )

prefix ,

Method that generates the CRA messages, called periodically

342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365

def

graph_handler ( s e l f ) : """ Periodically all routes it reasserts sees that all current its routes into the graph , uses it and , it then floods used by commit the that check a

pass

suppression modes

modes

the into

methods the

routes if

validity are

against to

suppression the

then

insert message

graph

( namely

accept ()

method

there

paths to

send it

generate

a CRA

flood

it .

cleans cleans """

the the

graph log to

keep it

live

keep

live

payload , s i z e

{} ,0

for

( prefix , entry )

for

route

in
=

in

s e l f . bgp_table . i t e m s ( ) :

entry . routes . values ( ) : t u p l e ( ( s t r ( s e l f . a d v e r t i s e d _ a s )+ " "+r o u t e [AS_PATH_LOC ] ) . s t r i p ( ) . s p l i t ( ) )

as_path

if

s e l f . g r a p h . a c c e p t ( p r e f i x , as_path , 2

ASSERTION_RATE ) :
= [ as_path ]

i f p r e f i x not in p a y l o a d : p a y l o a d [ p r e f i x ] e l s e : p a y l o a d [ p r e f i x ] . append ( as_path )

size + = 1 0 : = CRA( s e l f . a d v e r t i s e d _ a s , p a y l o a d , 2 = s e l f . c r y p t e r . s i g n ( message )

if

size

>

message message

ASSERTION_RATE, G l o b a l s . TIME ,

s e l f . SEQ)

s e l f . SEQ + = 1 s e l f . f l o o d _ m e s s a g e ( m e s s a g e , None ) s e l f . graph . c l e a n _ e x p i r e d ( ) s e l f . clean_log ()

36

8.7 Graph.py
We have included for this module the methods that handle suppression/re-suppression lters. We have omitted methods that handle the maintenance(expiry/addition/deletion) of this modules internal store. We have also omitted the classes that describe the structures used for the internal store of this module e.g. path store, triple store.

Listed:
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128

30% of module code

s u p p r e s s ( s e l f , as_path , p r e f i x ) : """ Applys @param @param the activated : : if the the this suppression prefix AS PATH path modes in this simulation to a path seen for a prefix

def

prefix as_path True

seen

for not

the be

prefix added to the graph , False otherwise

@return : """

should

SUPPRESSION =

G l o b a l s . SUPPRESSION = = 0 :

return F a l s e and s e l f . i s _ c l o s e s t ( a s _ p a t h , p r e f i x ) ) or \ (TRIPLES_NOT_IN_MAP in SUPPRESSION and s e l f . h a s _ t r i p l e s _ n o t _ i n _ m a p ( a s _ p a t h , p r e f i x ) ) or \ (NOT_SUBSET_OF_CLOSEST in SUPPRESSION and s e l f . i s _ n o t _ s u b s e t _ o f _ c l o s e s t ( a s _ p a t h , prefix ))) return T r u e return F a l s e
SUPPRESSION

i f l e n ( SUPPRESSION ) i f not ( ( CLOSEST in

def

r e a s s e r t ( s e l f , as_path , p r e f i x ) : """ Applys however modes @param @param prefix as_path True : : if the the this prefix AS PATH path the activated path is suppression a modes and in we this must simulation check that to it a path seen passes for the a prefix , suppression

this

reassertion

s t i l l

seen

for not

the be

prefix added to the graph , False otherwise

@return : """

should

SUPPRESSION = length =

G l o b a l s . SUPPRESSION

l e n ( as_path ) = = 0 of :

if
# a #

l e n ( SUPPRESSION ) map of by the the = list

return

True paths in our map for this prefix ,

equally

clos

keyed

paths

source

closest_paths src =

s e l f . get_closest_paths ( p r e f i x )

as_path [ l e n g t h

1]
mode is with on then the path must source be in one the of the equally close

if

CLOSEST # # If

in

SUPPRESSION : suppression for this

CLOSEST seen

paths

prefix

the :

particular

as_path

if

if
# #

as_path

in

closest_paths [ src ] [ 0 ]

TRIPLES_NOT_IN_MAP If

in
if

return
is

True

SUPPRESSION

: mode on then triple this will path must have atleast one

TRIPLES_NOT_IN_MAP such that count 2 :

suppression path 0 is

triple

the =

deleted

the

expire

#i . e

Refrence

if else :

if

l e n g t h <=

s e l f . t r i p l e s [ as_path ] [ 0 ]

1 = = 0

return

True

a ,b, c

length

3 , l e n g t h 2 , l e n g t h 1
1 = = 0:

while a != 1 : i f s e l f . t r i p l e s [ ( as_path [ a ] , as_path [ b ] , as_path [ c ] ) ] [ 0 ] return T r u e

a ,b, c = a

1 , b 1 , c 1

if

NOT_SUBSET_OF_CLOSEST # If

in

SUPPRESSION

: mode is on , then there should be no

NOT_SUBSET_OF_CLOSEST

suppression

37

129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

# #

path

such

that

this

path

is

a in

subset the

of

it

except

this

path

itself

becuase = =

its

obviously

s t i l l

map

size paths

closest_paths [ src ] [ 1 ] closest_paths [ src ] [ 0 ]

for

closest

if
#

in

paths

: :

closest If this = 1

= = as_path path is a

continue
of any path expet itself then fail

subset

index

while not ( i n d e x > s i z e or i n d e x > l e n g t h ) : i f c l o s e s t [ s i z e i n d e x ] == a s _ p a t h [ l e n g t h return F a l s e

index + = 1

index ]

and

index

!=

return return def

True

False

get_closest_paths ( s e l f , p r e f i x ) : """ Gets the paths stored in the graph that are equally close in terms of hop counts for a

prefix @return : """ closest # for = {} path that the table holds for the prefix L{map} in format C{ ( p r e f i x source , ( paths length , l i s t ( paths ) ) ) }

every

for

path #

in
=

s e l f . prefix_paths [ p r e f i x ] . paths . keys ( ) : is its first hop , ( in last index ) . BGP prepends

source

length src = src

l e n ( path )

path [ l e n g t h

1]
: = [ [ path ] , l e n g t h ] : then the other paths then reset the list of paths

if

not in
<

closest

closest [ src ]

elif
#

length if

closest [ src ] [ 1 ] path is = = closer length [ path ]

this

closest [ src ] [ 1 ] closest [ src ] [ 0 ]

elif
#

length if it

= = is

closest [ src ] [ 1 ] equally close

: add it to the list of paths

then

c l o s e s t [ s r c ] [ 0 ] . append ( p a t h )

return def

closest

i s _ c l o s e s t ( s e l f , as_path , p r e f i x ) : """ Returns for in the the true if this as_path of it to check path is for by previous definition , False otherwise is the the closest i . e . path no seen for the for prefix this prefix from this source

particular map is as

source as

path

other

path

close the

@param @param

as_path : prefix : True

path prefix

the if

the is

@return : """ # if we

as_path

the

closest

dont

even

have

the

prefix

then :

obviously True

its

the

closes

if

prefix

not in
=

s e l f . prefix_paths

return

closest_paths length src = =

s e l f . get_closest_paths ( p r e f i x )

l e n ( as_path )

as_path [ l e n g t h

1]
:

i f s r c not in c l o s e s t _ p a t h s i f c l o s e s t _ p a t h s [ s r c ] [ 1 ] >= return F a l s e def

return
:

True

length

return

True

ha s _t ri pl es _n ot _i n_ ma p ( s e l f , as_path , p r e f i x ) : """

38

188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225

Returns @param @param

true

if

this the the

as_path path to

has check

triple

not

previously

known

to

this

graph

as_path : prefix : True

prefix

the has

path

is

for on triple no in the map , False otherwise

@return : """ length =

if

as_path

atleast

l e n ( as_path ) 2 :

if

l e n g t h <=

else :

if

as_path

not in

self . triples

return

True

a ,b, c

length

3 , l e n g t h 2 , l e n g t h 1
self . triples :

while a != 1 : i f ( a s _ p a t h [ a ] , a s _ p a t h [ b ] , a s _ p a t h [ c ] ) not in return T r u e

a ,b, c = a

1 , b 1 , c 1

return def

False

i s _ n o t _ s u b s e t _ o f _ c l o s e s t ( s e l f , as_path , p r e f i x ) : """ Returns this true if this as_path source to check path a is for of any prefix seen for the path , False otherwise is not a subset of any prefix seen for this path with

paths

particular the the if

@param @param

as_path : prefix : True

path prefix

the is

@return : """

as_path

not

subset

if

prefix

not in
=

s e l f . prefix_paths

return

True

closest_paths length src = src = = =

s e l f . get_closest_paths ( p r e f i x )

l e n ( as_path )

as_path [ l e n g t h

1]
:

if for

not in in
1

closest_paths

return

True

size paths

closest_paths [ src ] [ 1 ] closest_paths [ src ] [ 0 ] paths :

closest index =

while not ( i n d e x > s i z e or i n d e x > l e n g t h ) : i f c l o s e s t [ s i z e i n d e x ] == a s _ p a t h [ l e n g t h return F a l s e

index + = 1

index ]

and

index

!=

return

True

8.8 PVP.py
We have included for this module the core algorithm for our overlay protocol, we have omitted the structure (Table_Entry) that the algorithm makes use of as it is very similar to a BGP structure previously listed.

Listed:
7 8 9 10 11 12 13 14 15 16 17

85% of module code

class

PVP :

""" This class is a description of an instance of our overlay protocol running on

som E S W D machine @ivar @ivar @ivar @ivar @ivar """ routing_base : session_info : changes : holds the maps the routing its list the to table of the instance to exponential whose an enties dist . have metrics changed was received

EWSDs of last the

sessions

destinations time at

last_change : daemon : a

holds

which object

announcment this

refrence

L{Daemon}

owning

protocol

def

__init__ ( s e l f , daemon ) :

39

18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

s e l f . routing_base s e l f . session_info s e l f . used_sessions s e l f . metric_vector s e l f . changes = {}

= =

{ daemon . a d v e r t i s e d _ a s {} [] 0

T a b l e _ E n t r y ( ' ' , 0 ,LOCAL) }

= =

s e l f . last_change

G l o b a l s . TIME

s e l f . daemon = daemon

def

session_up ( s e l f , s e s s i o n ) : """ Called @param """ s e l f . session_info [ session ] s e l f . metric_vector # Send the full + = 1 over that session = 20 by the owner E S W D the to indicate that a new just session been has come online

session :

L{ P 2 P _ S e s s i o n }

that

has

bought

online

s e l f

. metric_vector

RIB

s e l f . g e n e r e r a t e ( s e s s i o n , s e l f . s e s s i o n _ i n f o [ s e s s i o n ] , True )

def

session_down ( s e l f , s e s s i o n ) : """ Called @param """ by the owner E S W D the to indicate that a session just has come offline offline

session :

L{ P 2 P _ S e s s i o n }

that

has

been

bought

del for def

s e l f . session_info [ session ] destination

in

s e l f . routing_base . keys ( )

: session )

s e l f . handle_session_withdraw ( d e s t i n a t i o n ,

handle_session_withdraw ( s e l f , d e s t i n a t i o n , s e s s i o n ) : """ Handles a a RIB a session a withdrawal is event , called for every destination for session within

when

session

bought when the

offline , it is

likewise

called a

particular

destination :

withdrawn

from was it

particular withdrawn

@param @param """ entry =

destination session :

holds the

destination that

that

holds

session

withdew

s e l f . routing_base [ d e s t i n a t i o n ]

for

route_id # remove

in
any

entry . r o u t e s . keys ( ) : route heard from the session : for the destination

if
# If

entry . r o u t e s [ route_id ] [ 2 ]

= =

session

del

entry . r o u t e s [ route_id ] route was withdrawn , then : , will be sent next simstep either implicit / explicit replace

the

best

if

entry . best_route

if

not in

entry . routes :

len ( entry . routes )

= = 0

# EXPLICIT

else

del
: #

s e l f . routing_base [ d e s t i n a t i o n ] implicit , , metric will be sent , next simstep

winner

= None

float ( ' inf ')

for

id , r o u t e

if

in
,

entry . routes . items ( ) : < metric winner = = : route [ 1 ] , id

route [ 1 ] metric

entry . best_route # flag this

winner as changed = 1

destination

s e l f . changes [ d e s t i n a t i o n ] s e l f . last_change =

G l o b a l s . TIME

def

r e c e i v e ( s e l f , s e s s i o n , packet ) : """ Process @param an RPO session : message the received the by the E S W D owner received on

session

RPO was

40

77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135

@param

packet :

the

message / packet

""" payload rib = = p a c k e t . g e t S t a t e ( "PA LO Y AD" )

s e l f . routing_base

for

destination

if

in

payload [ 1 ] :

# WT D W L I H A A S : session )

destination

in

s e l f . routing_base

s e l f . handle_session_withdraw ( d e s t i n a t i o n ,

for

d e s t i n a t i o n , path , m e t r i c

if if

in

payload [ 0 ] :

# UPDATES

s t r ( s e l f . daemon . a d v e r t i s e d _ a s )

continue
+ = destination

in

path . s p l i t ( ) :

metric

s e l f . session_info [ session ]

not in

rib

: = Table_Entry ( path , m e t r i c , s e s s i o n )

s e l f . routing_base [ d e s t i n a t i o n ] s e l f . changes [ d e s t i n a t i o n ] = 1

else :
entry best = = s e l f . routing_base [ d e s t i n a t i o n ] entry . routes [ entry . best_route ]

if

session

in

e n t r y . heard_from_to_id

: = ( path , m e t r i c , s e s s i o n )

e n t r y . r o u t e s [ e n t r y . heard_from_to_id [ s e s s i o n ] ] id = e n t r y . heard_from_to_id [ s e s s i o n ]

else if

: id = e n t r y . add_route ( path , m e t r i c , s e s s i o n ) > metric : = id = 1

best [ 1 ]

entry . best_route

s e l f . changes [ d e s t i n a t i o n ] s e l f . last_change =

G l o b a l s . TIME

def

g e n e r e r a t e ( s e l f , s e s s i o n , metric , f u l l _ r i b """ Create @param @param @param just """ and transmits the the a routing packet

False ) :

constructed routing

for

particular is for

session

session : metric :

L{ P 2 P _ S e s s i o n } metric of this

this

packet

session the whole routing table must be sent or

full_rib :

indicates

whether

changes

if full_rib else : keys

payload rib = =

: =

keys

s e l f . routing_base

s e l f . changes

( [ ] , [ ] )

s e l f . routing_base

for

destination

if

in
it

keys :

destination # means

not in
has

s e l f . routing_base withdrawn with

: no alternative routes hence deleted

been

p a y l o a d [ 1 ] . append ( d e s t i n a t i o n )

entry route path

= = =

rib [ destination ] entry . routes [ entry . best_route ] route [ 0 ] + ' ' + s t r ( s e l f . daemon . a d v e r t i s e d _ a s )

p a y l o a d [ 0 ] . append ( ( d e s t i n a t i o n , path , r o u t e [ 1 ] ) )

message message

= P P V M( s e l f . daemon . a d v e r t i s e d _ a s , p a y l o a d , G l o b a l s . TIME , s e l f . daemon . SEQ) = s e l f . daemon . c r y p t e r . s i g n ( m e s s a g e )

s e l f . daemon . SEQ + = 1 s e s s i o n . t r a n s m i t _ m e s s a g e ( s e l f . daemon . i p , m e s s a g e )

def

calculate_used ( s e l f ) : """

41

136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168

Called stores """

upon which

convergence / reconvergence sessions are not

of

this i . e .

protocol appear in

instace , the

identifies table

and

redundant ,

routing

sessions

{}

for

destination , entry session =

in
:

s e l f . routing_base . items ( ) :

entry . routes [ entry . best_route ] [ 2 ] = = LOCAL =

if

session

continue

sessions [ session ]

True

s e l f . used_sessions #i f #

s e s s i o n s . keys ( ) < len ( s e l f . session_info ) :

len ( s e l f . used_sessions ) print

' Saved ' , l e n ( s e l f . s e s s i o n _ i n f o )

len ( s e l f . used_sessions )

def

simulate ( s e l f ) : """ Called by the owner E S W D ( L{Daemon } ) to simulate its protocol instance

"""

if

len ( s e l f . changes ) # send changes

!=

: sessions :

over

all

for

session , metric

in

s e l f . session_info . items () metric )

s e l f . genererate ( session , s e l f . changes . c l e a r ( )

if

s e l f . last_change # Convergence

G l o b a l s . MINUTE <=

G l o b a l s . TIME :

test + G l o b a l s . MINUTE = = G l o b a l s . TIME :

if

s e l f . last_change # Just converged

s e l f . calculate_used () # tell the E S W D to proceed with normal operation

return return

True

False

42