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 su�ers 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 pre�x 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 pre�x hijack attacks in there various

forms quiet e�ectively 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 e�ective solution that can be seamlessly deployed by ISPs.

2

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.

3

Contents

1 Introduction 7

1.1 Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Pre�x Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Related Work 14

2.1 Secure BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Secure Origin BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Pre�x Hijack Alert System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Inter-domain Route Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Requirements and Analysis 18

3.1 BGP Threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Early Warning System Threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Metrics for success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Requirements for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Simulator Design and Implementation 21

4.1 Con�guration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Topology Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Simulation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Simulation Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5 BGP Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.6 Early Warning System Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7 Evaluator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.8 Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Early Warning System Design and Implementation 24

5.1 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 EWSD net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4

5.2.1 Con�gured Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2 Random Peers / RPR messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.3 Post peering communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Routing Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.1 Reasons and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.2 Distance Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.3 Link State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.4 Path Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Inter-daemon communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.1 Tree Based Flooding Vs Indiscriminate Flooding . . . . . . . . . . . . . . . . . . . 29

5.4.2 Message Loop Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.5 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.1 Building the certi�cate store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.2 Detecting and Propagating Con�icts . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.3 Periodic Key Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5.4 Verifying messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.6 Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.6.1 Path store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.6.2 Triple store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.6.3 Triple history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.7 Building the graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.7.1 Current Route Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.7.2 CRA Messages Periodicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.7.3 CRA Messages Time to live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.7.4 Accepting Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.8 Maintaining the graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.8.1 Triple and Path expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.8.2 Building trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.8.3 Reviving Triples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.9 Perspective suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5

5.9.2 TRIPLES NOT IN MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.9.3 CLOSEST ONLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.9.4 NOT SUBSET OF CLOSEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.9.5 Combining suppression modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10 Daemon on Daemon Threat and Attack detection . . . . . . . . . . . . . . . . . . . . . . . 35

5.10.1 False Autonomous System representation . . . . . . . . . . . . . . . . . . . . . . . 35

5.10.2 Message tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10.3 Replay attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10.4 Random peering attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10.5 Tampering with Path Vector Protocol overlay . . . . . . . . . . . . . . . . . . . . . 35

5.11 BGP Threat and Attack detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.11.1 Detecting pre�x hijack attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.11.2 Detecting policy violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.11.3 Third party threat detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Testing and Solution Analysis 38

6.1 Validating BGP Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2 Validating solution behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Protection capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.4.1 First party detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.4.2 Third party detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4.3 EWSD Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4.4 Cost and scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4.5 Stopping Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Conclusion and Evaluation 50

7.1 How well does it work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3 Self evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8 Bibliography 52

6

1 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 in�uence and

the ability to detect and deal with malicious attacks. Attacks against technologies can come in many

di�erent 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 a�ected 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 brie�y 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 e�ects,

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 con�gured 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

a�ected 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

and provide early warnings when such information is detected. We aim to build a system that will be

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.

7

1.1 Border Gateway Protocol

BGP is an inter-domain routing protocol, its purpose is to communicate reachability information for

pre�xes 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 identi�es 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 pre�xes 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 pre�xes within this messages [NLRI], it will reach its destination

• [Path Attributes] describes the route i use when routing to pre�xes within this messages [NLRI]

• I am no longer willing to route to pre�xes 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 pre�xes.

8

Attribute Description In�uence

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

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.

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

MED This attribute is used when two ASes have multiple

connection points, it is used by the advertiser of a

route to in�uence which of these connection points

the receiver should use for routing i.e. (choose as its

best route)

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.

iBGP Indicates whether this route was heard from the

same AS through an iBGP session or heard from

another AS through eBGP session.

Paths that have not been selected as best routes due

to the previous attributes will be in�uenced by this

attribute . BGP chooses a path learned through

eBGP over a path learned over iBGP

[Table 1]

BGP will process every pre�x within the NLRI of an update message it hears over a BGP session. To

process a pre�x BGP will �rst add the route described by this message to the list of routes known for

that pre�x, 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 in�uence 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

9

is the COMMUNITY attribute which is an instrumental tool in enforcing policies. BGP routers generally

class peers by one or more classi�ers 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 pre�x 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 a�ected the paths each router learned for the pre�x 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. BGP routers generally consider routing information heard from a BGP peer to be

valid. 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 miscon�guring 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 pre�xes and/or black-hole this data.

How pre�x hijacking works?

Pre�x 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 e�ectiveness of these attacks.

This group of attacks aims at giving the attacker access to data destined for a pre�x. 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 pre�x 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

pre�x 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 LOCAL-

PREF 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

• An AS that if attracted guarantees more ASes will also attract to the attackers route.

• An AS that if attracted increases the probability of attracting more ASes

[Figure 5] shows an example of an attack on BGP. It shows the paths learned and chosen by ASes within

a topology for a pre�x advertised by a router at AS(1023). It then shows the e�ects of an attack by

AS(8009) which makes one of its routers advertise an empty AS-PATH for the pre�x i.e. (claiming that

it also owns the pre�x). We will discuss key points in this attack that generally apply to pre�x hijacking

attacks.

11

1. Knowing more information about the current routes held by an AS for a target pre�x 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 e�ective 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 pre�x; 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 e�ect, where di�erent subsets of ASes select routes that are destined

for di�erent sources. In this attack the topology has partitioned on the target pre�x.

1.3 Pre�x Hijacking

We brie�y discussed pre�x hijacking; However, our mention of pre�x hijacking was for introductory pur-

poses and does not meet the level of understanding required for this project. In this section we would like

to elaborate on the speci�c types of pre�x hijacking an attacker can mount, how the attacker can mount

them and the prerequisites for the attack to be successful.

Valid pre�x attack is an attack on a pre�x where the attacker advertises a malicious route for a pre�x

that has been explicitly advertised by another AS.

Direct pre�x hijacking is a variant of a valid pre�x attack where the malicious route claims through its

AS-PATH attribute that the attacker is the origin (owner) of the target pre�x. To do this the attacker's

advertised route will have an AS-PATH attribute with the �rst hop as his ASN.

Indirect pre�x hijack is a variant of a valid pre�x attack where the malicious route preserves the target

pre�xe'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 pre�x.

Invalid pre�x attack is an attack on a pre�x where the attacker advertises a malicious route for a pre�x

that has either been implicitly advertised by another AS or not advertised at-all.

12

Deaggregation pre�x hijack is a form of invalid pre�x attack where the advertised route is for a sub-

pre�x of a valid pre�x being advertised by some AS. This attack is very e�ective because BGP implements

longest pre�x match where it will use the most speci�c pre�x that the destination IP of a packet falls under

to route to. Since this sub-pre�x has not been advertised by any other AS the attackers advertisement

could be widely accepted by other ASes thereby making this attack very e�ective.

e.g. AS(X) advertising 29.0.0.0/8, Attacker advertises 29.19.10.0/24

Aggregation pre�x hijack is a form of invalid pre�x attack where the advertised route is for a pre�x

whose sub-pre�xes are being advertised by some ASes. As previously mentioned BGP implements longest

pre�x match and hence this attack may seem redundant. However, if any sub-pre�xes of the attacked

pre�x being advertised by other ASes are withdrawn, the attacker will have access the the pre�x space of

the withdrawn sub-pre�xes from all the ASes a�ected by their attack.

e.g. AS(X) advertising 30.10.0.0/16, Attacker advertises 30.0.0.0/8

1.4 Problem Statement

Pre�x hijacking is the most prominent security issue with BGP, if used correctly this group of attacks could

in�ict serious damages on a target pre�x. In response to this security issue several secure implementations

of BGP have been developed that either partially or wholly protect against pre�x 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 in�ux 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 bene�ts 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 pre�x 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 e�ect 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 pre�xes

occur. Instances of our solution running on di�erent ASes will be able to communicate through con�gured

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 e�ect of pre�x hijacks[Figure 7].

13

We anticipate that our design will provide an easy and inexpensive BGP security solution that detects

and warns against pre�x 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 e�ectiveness 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 e�ectiveness in detecting pre�x hijack attacks.

We also aim to identify the advantages and disadvantages of the approach we took to solving this problem,

more speci�cally we would like to answer questions such as:

• Can our solution stop pre�x hijack attacks or does our approach limit us to only being able to detect

and warn against pre�x hijacking?

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

implementation?

2 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 pre�x hijacking.

2.1 Secure BGP

Secure BGP (S-BGP) is a reimplementation of BGP that provides origin authentication and path

veri�cation . Origin authentication allows S-BGP routers to verify that the originator of an update

message is authorized to advertise all the pre�xes within the messages NLRI. Path veri�cation 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 certi�cates. To verify an update message an S-BGP router requires the following:

• Address Attestations(AA) for each organization that owns a pre�x within the messages NLRI. AA's

are used by organizations to authorize ASes to originate pre�xes 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 pre�xes, within an update message's NLRI, through the

update messages AS-PATH.

• Certi�cate'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 pre�x 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 veri�es the sub AS-PATH { ASi, ..., ASorigin }, the NLRI and ASi+1

S-BGP's operation provides robust protection against pre�x 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 o�er this protection each AS must have the following resources stored in a trusted database.

• Entity Certi�cate(EntityCert) containing the public half of the ASes public/private key pair

• Authentication Certi�cate(AuthCert) that authorizes the AS to advertise a set of pre�xes listed in

the certi�cate, and delegate authority over pre�xes/sub-pre�xes to other ASes

• AS Policy Certi�cate(ASPolicyCert) 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 pre�x there must be a chain of AuthCert delegations between the update's origin

and the owner of the pre�x. soBGP will verify the origin of all pre�xes seen within the NLRI of the update

message.

soBGP's operation mitigates the threat of pre�x hijacking; However, as a product of soBGP only verifying

route existence an attacker can still mount e�ective pre�x 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 pre�x with the correct origin with the following AS-

PATH {ASattacker,ASn,ASorigin}. Physically this route exists; However, ASnwill not usually advertise

routing information heard from the origin AS to the attackers AS.

Although soBGP does not wholly solve pre�x 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. Imple-

mentations of soBGP have been developed and tested; However, hardly any ISPs have adopted it. Even

though soBGP o�ers a substantial increase in BGP security, changing BGP implementations remains to

much of a risky choice for ISPs.

2.3 Pre�x Hijack Alert System

Pre�x Hijack Alert System (PHAS) is a system that aims at providing pre�x owners warnings when an

attacker hijacks any of the pre�xes they own. PHAS takes advantages of currently established route

monitors as its source of routing information. Route monitors typically have peering agreements with

hundreds of ASes that allow them to view real time BGP updates from many di�erent perspectives.

PHAS takes input from such monitors and uses this input to detect pre�x hijacks. As illustrated in [�gure

8] PHAS is composed of several sub systems:

• The Origin Monitor processes real time data heard from BGP monitors. It maintains for each

registered pre�x a set of ASes originating it as revealed by the processed monitor data, this set is

called the Origin Set. PHAS maintains an Origin Set for each pre�x registered by a user of the

system. Changes in the Origin Set of a registered pre�x trigger Origin Events.

16

• The Noti�cation Transmitter processes Origin Events. It decides on what events it should ac-

tually warn on, then sends a signed email noti�cation to the client that registered the pre�x whose

Origin Set has triggered this event.

• The Local Noti�cation Filter automatically processes received noti�cation emails. It veri�es

noti�cations by checking their signatures. Veri�ed noti�cations are then passed through a client

con�gured �lter. Using this �lter the client can choose to ignore noti�cations that meet certain

criteria.

• The User Registration system allows a pre�x owner to register a pre�x for monitoring.

The basic design of the system allows registered owners of pre�xes to receive slightly delayed warnings

when one of their registered pre�xes are DIRECTLY hijacked. Proposed extensions to PHAS would allow

the system to detect and inform registered pre�x owners of INDIRECT and DEAGGREGATION pre�x

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 con�gured 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 con�gured 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 be-

tween 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 e�ective 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

3 Requirements and Analysis

3.1 BGP Threat model

To model the threat of BGP pre�x hijacking we chose to identify classes that describe the di�erent

behaviors and motivations of malicious ASes. We have identi�ed four distinct classes that describe the

nature of a malicious ASes behavior :

Interceptor Describes ASes that choose to carry out any form of pre�x hijacking as previously described.

They do so with the intention of manipulating/black-holing data destined for the target pre�x.

We assume these ASes do not try to preserve a route to the original owner of the target pre�x.

Attractor Describes ASes that also choose to carry out any form of pre�x hijacking as previously de-

scribed. 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 pre�x of their attack, to the pre�xes

known owner. We assume these ASes carefully choose their attacks to preserve a route to the

original owner of the target pre�x.

Erroneous Describes the set of ASes that have one or more incorrectly con�gured BGP routers. These

erroneous con�gurations 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 e�ectiveness of another malicious ASes pre�x hijack attacks.

We have also identi�ed several classes that describe the general motivation behind a malicious ASes

behavior. Furthermore, we have identi�ed, for each class, the associated behaviors that can be expected

from ASes that fall under it.

Class Description Behavior

NOC

Takeover

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

identi�ed behavior classes

Interceptor,

Attractor,

Erroneous,

Colluder

Agenda ASes that intentionally mount or aid pre�x 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 identi�ed classes. However, we do not expect their behavior to be

�Erroneous� as no AS will intentionally miscon�guring its infrastructure

Interceptor,

Attractor,

Colluder

Non

Malicious

ASes that have no motivation behind mounting an attack yet the have seemingly

mounted one. These ASes are non malicious but miscon�gured

Erroneous

Partial

Takeover

ASes that have had some of their routers taken over by an adversary. With this

takeover the adversary has complete control of some of the AS's BGP routers

Erroneous,

Interceptor

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 pre�x 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 di�erent 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 specif-

ically targeted by an attacker with a pre�x 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

an EWSD will periodically inform all other EWSDs of the current routes it can see. EWSDs use this

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 certi�cates they receive from one another, collisions could occur. For example, two

19

EWSDs (one of which is malicious) broadcast di�erent certi�cates 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 o�ine.

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 speci�c attacks that

they guard against and the adverse e�ects 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:

E�ectiveness Maximizing the percentage of pre�x hijack attacks that can be detected by our

solution.

Cost Minimizing the cost incurred by an AS deploying an instance of our solution.

Scalability Ensuring that the growth in our solution's cost as more EWSDs are bought

on-line is manageable.

Security 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 e�ectiveness.

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

4 Simulator Design and Implementation

4.1 Con�guration 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 de�ned our own syntax/language that allowed us to

intuitively describe topologies within this component. Furthermore, this �le allows the user to de�ne some

attributes that control the simulator's behavior.

4.2 Topology Generator

The topology generator is a python script that automatically generates random topologies, it outputs the

topologies it generates to the �Con�guration File� in our de�ned syntax. This component takes as input

certain con�guration parameters de�ned in another con�guration �le, these parameters in�uence 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 topol-

ogy de�ned in the con�guration �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 simula-

tion 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 modi�cations 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 di�cult.

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 con�guration 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 re�ectors

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 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.

Session Handler Manages all the sessions that an EWSD has bought up. This includes sending

and receiving messages and post peering communication.

Graph 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.

Routing Protocol This component runs a modi�ed 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 e�ect an automated client. This component automatically

generates topologies using the topology generator, following which this component will invoke the simula-

tion 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 speci�c data from the statistics component[Figure 9]. The evaluator com-

ponent has multiple methods/tests that can be invoked by the user, each test evaluates a di�erent 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 brie�y 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

5 Early Warning System Design and Implementation

Previously we have introduced this project, elaborated on our aims and goals and detailed how the simula-

tor 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 pre�x 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 certi�cate 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 certi�cate 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 di�erent 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 e�ectiveness, 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 Con�gured Peers

When an EWSD is bought on-line by an AS it must be con�gured with a number of IP addresses of

other EWSDs. This set of IP addresses would be con�gured 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 con�gured 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 con�gure a FANOUT attribute that describes their desired number of P2P sessions. Pe-

riodically 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 certi�cate 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. How-

ever, the EWSD net does not form a complete graph i.e all instances within the net can directly com-

municate 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 sure that if it sends a message over all of its

sessions it will reach all other EWSDs.

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 di�ers from the traditional path vector protocol in that it will choose, for each en-

try/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 identi�es 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/o�ine. This proved to be a huge problem, namely this presented us with

the Count-To-In�nity problem associated with Distance Vector Protocols. We attempted to rectify our

implementation by including features that mitigate the e�ects 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 o�ine 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 e�ect 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 di�ers 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 di�erent

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

in�nitely 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 veri�cation 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/certi�cate is heard from its source.

5.5 Public Keys

For security reasons we require that every EWSD broadcast over the EWSD net a certi�cate 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 ine�ective. We have chosen not to

assume an authoritative source that distributes these certi�cates since this will break our goal of making

our solution easily deployable. As an alternative we have implemented into our solution a certi�cate

distribution mechanism.

5.5.1 Building the certi�cate store

An EWSD exchanges both its personal certi�cate and all other certi�cates it has in its storage over any

newly established P2P session, EWSDs that receive new certi�cates will store and �ood them. We require

that EWSDs swap their whole certi�cate 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 certi�cates.

A certi�cate 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 certi�cates themselves are tamper proof.

5.5.2 Detecting and Propagating Con�icts

When an EWSD sees a new certi�cate, attempting to bind a public key to an ASN that it already has

binding for, it detects a con�ict. Con�icting PKE messages are �ooded by the EWSD that detects them,

this allows a con�ict 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 certi�cate (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 veri�ed at the receiver. To do this every

message must contain the ASN of its sender. The receiver uses this attribute to lookup its certi�cate store

for its associated public key. Following this look up, the signature of a message is veri�ed and compared

with the actual hash value of the message at the receiver. If the veri�ed signature di�ers 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 veri�cation 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 di�erent 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 pre�x to the set of AS-PATHs seen for it in all the di�erent 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 path

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 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 pre�x 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 reference this triple. The second value is a trust

31

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 triple history where they will remain

until they are revived or deleted.

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 pre�x known by its originator, the

list of AS-PATHs known for the pre�x. 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 signi�cantly 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 path store. In our implementation the

periodicity of CRAs is con�gurable (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 detection is not as critical as if

we were trying to stop 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 di�cult. 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 triple store. A triples reference count attribute indicates how many

paths, within the path store, exist that have a reference to it. 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 triple

history . We instantiate the triple with the trust metric held for it within the triple history (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 perspec-

tive 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 di�erent types of suppression modes we have implemented, what infor-

mation they eliminate and what types of attacks we can detect with them. Recall the di�erent forms of

pre�x 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 pre�x granularity. For example, for every pre�x within a

perspective process every AS-PATH associated with it.

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 pre�x, 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 pre�x

• 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 identi�ed length, or A reveals a new origin/pre�x 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 pre�x

hijack attacks. In summary, this mode deterministically rids of all the AS-PATHs that do not reveal a

new origin for a pre�x.

5.9.4 NOT SUBSET OF CLOSEST

This mode basically ensures that an AS-PATH (A), associated with some pre�x, would only pass if the

following conditions hold:

• (A) does not overlap with the closest path currently held for its associated pre�x.

• (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

pre�x 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 pre�x.

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 certi�cate (PKE) attempting to bind an already bound AS number

to a public key. Our solution could easily detect this attack as our certi�cate distribution mechanism

ensures that these con�icts are globally propagated. In summary, If an EWSD receives a PKE message

claiming to be originated by it, and a di�erence exists between the EWSD's key and the key within the

PKE, then this reveals a con�ict 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 veri�cation 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 signi�cant portion of RPRs.

Finally, a malicious EWSD may also attempt to bring o�ine 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 con�gured

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 signi�cantly reduce the cost of �ooding

messages over the EWSD net. However, the use of this protocol bought to light signi�cant 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/veri�cation 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 mech-

anisms 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 signi�cant 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 an-

nouncement 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 pre�x hijack attacks

To detect pre�x hijack attacks an EWSD must be con�gured with the following lists :

Pre�xes Pre�xes owned by its AS. Automatically detected via the EWSD's perspective.

Peers ASes that have peering relationships with the AS they are representing

Atomicity Non atomic pre�xes 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 any routes to one another. This means that the EWSD

would not see the peer in its perspective.

Direct If a pre�x, within the local pre�xes list, is attached to an AS within the graph

di�erent from the EWSD's AS

Indirect 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.

Deaggregation If a deaggregation of a pre�x, within the local pre�xes 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 con�gured 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 peers class list

• Check the identi�ed classes against the secretly kept 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 pre�x our implementation and design rely on the following

• The correct valid path for the pre�x has been advertised �rst

• The attacker claiming a new path to the pre�x, 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 pre�x 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 signi�cantly longer over the EWSD's lifetime.

6 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 con�rm 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 di�erent layers of abstraction. The client can

also graphically trace routes heard over BGP, for a certain pre�x, within these representations [Figure

12]. With both these tools we ran many simulations, injecting many di�erent 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

re�ectors 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 pre�x

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 signi�cantly more complex, at di�erent 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 Customers of Tier-1 ASes and providers of Tier-3 ASes. Tier-2 ASes could peer with one another

Tier-3 Customers of Tier-2 ASes. Tier-3 ASes could 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 LOCAL-PREF Reason

customers 1000 Routes generate revenue

peers 500 Routes are free (conditional)

providers 100 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 o�ers. [Figures 18 &

19] show the global/combined protection against the di�erent types of pre�x 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 re�ect 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 approx-

imately 20% of ASes had deployed EWSDs, the EWSD net would have spread globally by traversing

peerings and partially engul�ng 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 di�erent perspectives/EWSDs.

41

We would now like to perform some further analysis to discover how the growth of the EWSD net e�ects

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 pre�x

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 e�ectiveness 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 e�ectiveness at lower deployment levels. However, no

matter what the policies are, as deployment tends towards 100% their e�ect on our solution's e�ectiveness

becomes negligible.

After thoroughly investigating the cause of the variance in the detection rate of attacks for ASes run-

ning 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 con�rm our conclusion we pro-

grammed 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 di�erent 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 �modi�ed 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 false positives but can never cause false

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:

• The attacker's/colluder's EWSD advertises CRAs that show other ASes attacking its target pre�x

• The attacker then mounts his BGP attacks on the target pre�x

• The EWSD ran by the target pre�x'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 e�ects of this threat.

Recall that an EWSDmonitors 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 identi�ed 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 certi�cates). 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 Identify the rate of attacks that we consider to be average/normal for each EWSD to

trigger e.g. 2 attack per hour. Keep the latest time at which each source EWSD has revealed

an attack. 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 di�erent approach that aims at rapidly decaying our trust for an EWSD's

CRAs as he sustains his possibly malicious behavior.

if 1− e−2(time−last 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 a�ected 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 di�cult 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 di�cult. 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 di�cult 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). This mechanism is intended to allow an EWSD to detect

when a new untrusted route is seen for any pre�x. However, from our analysis we have found that our

third party detection mechanism can be easily bypassed by an attacker. Furthermore, it is only e�ective

in detecting third party indirect pre�x hijack attacks.

44

Our third party detection mechanism works quiet well for indirect pre�x hijacks. If the attack makes it into

any perspective exchanged over the EWSD net then it will de�nitely 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 pre�xes are allowed to be deaggregated and likewise

some pre�xes 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 pre�x hijack (Section 1.3) and

associate with it the path he will use in his future attack. Since this initial attack is against a pre�x not

allocated for use over the Internet, then no EWSD will detect any threat. The attacker keeps his unused

pre�x hijack alive for some time, by doing so EWSDs build trust for all the triples within the routes seen

for the unused pre�x. 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 signi�cant, it has a direct e�ect

on the quality of the perspective that an EWSD can build on behalf of its AS. It does not su�ce 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 pre�x [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 con�gure. Our recommended deployment strategy is for

EWSDs to peer with the leaf routers of the route re�ector [Figure 4] tree within their AS. This will allow an

EWSD to capture a signi�cant 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 4+ Cores , 2.0 GHz + Multiple cores to parallel message veri�cation and processing

RAM 4 GB+ DRAM Holds cached graph data, certi�cate 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 signi�cantly, 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 su�er 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 o�ine 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 bene�ts.

Scalability analysis

Messages sent over an EWSD net are signed, this means that every single message received needs to be

veri�ed, 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 e�ects the delay between an attack taking

place and its detection. With these trade-o�s 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 recom-

mended 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 pre�x 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 pre�x i.e. the perspective for the AS that owns

each pre�x has the shortest(empty) AS-PATH in our abstract routing table. Now imagine that only X

percent of pre�xes 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 pre�x there could be many perspectives with equally short AS-PATHs and hence their all

sent by this suppression mode.

There is a seesaw e�ect here, at low EWSD deployment, were less likely to have multiple equal length

AS-PATHs for a pre�x, at higher EWSDs deployment, there are more pre�xes that have only one closest

AS-PATH. So we generalize and say that a single AS-PATH is sent for each pre�x 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 Total AS-PATHs Unique AS-PATHs Unique Triples Passed Suppression

41,082 30,437,598 4,075,845 1,201,105 1,121,190

Our analysis of the routing tables showed that ~1.1 million AS-PATHs pass this suppression mode. This

number re�ects 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

pre�xes 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 pre�x 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 32 MB of unique CRA messages

per hour.

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, re�ect the average amount of redundant messages seen by an EWSD. Our research shows

that the recommended size of RSA keys/certi�cates 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

(EWSDs ∗ decryption time

#cores+

total − data

hash(rate)

)→ 1.2

(42, 000 ∗ 0.007

4+

32

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 worst

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

[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 pre�x, 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

7 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 route

validation. Similarly, our solution as a whole can provide origin authentication.

Our solution di�ers from S-BGP in that its individual instances (EWSDs) can only e�ectively 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 con�dent 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, e�ective and reasonably secure. However, our

solution does not and cannot (practically) solve/stop pre�x 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 di�erent 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 im-

plementation 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 e�ectively transposing our initial approach we can detect attacks correctly without sharing sen-

sitive 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 di�erentiate 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 Bibliography

[1] 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. Gri�n, 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):582�592, 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 pre�x 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] AS6447 BGP Routing Table Analysis Report

http://bgp.potaroo.net/as6447/

[9] 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 3

2 Interim Report 5

3 RIPE RIS Analysis 7

4 Simulator Requirements 7

5 Simulation Server 7

5.1 Automatic Topology Con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2 Manual Topology Con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3 Example topology con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.4 Starting the simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6 Simulator Client 14

6.1 Connecting to the simulation server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2 Commanding the simulation server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7 Other information 16

7.1 Modifying Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Code Listing 19

8.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.2 Code listings summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.3 Attacker.py code listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.4 BGP.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.5 BGP_Structures.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8.6 Daemon.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.7 Graph.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.8 PVP.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2

1 Project Plan

3

4

2 Interim Report

5

6

3 RIPE RIS Analysis

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

1. Navigate to the /ripe folder in our provided distribution

2. Execute gcc -o dumper dump_paths.c bgp_lib/libbgpdump.so -Wall

3. 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

4 Simulator Requirements

Python-2.6 To run our simulator, this is a critical requirement.

http://www.python.org/download/releases/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

5 Simulation Server

5.1 Automatic Topology Con�guration

Our simulator takes as input a con�guration �le located at ews/con�g/topology.con�g relative to the

distribution folder, this �le can be automatically generated using our generator script. The generator script

7

takes as input another con�guration �le at ews/con�g/generator.con�g, within this �le are con�gurable

parameters that are used by the script to generate the topology. The following are the attributes and

there purpose

FANOUT Integer Number of tier 1 ASes in the con�guration, dictates the size of

the whole topology. (NOT EWSD RPR FANOUT)

ROUTERS_PER_AS Integer Number of routers each AS within the simulation has. If

above 1 a route re�ector is used in each AS

T2_PEER_PROBABILITY Float The probability that a tier 2 AS brings up a peering class

BGP session with another tier 2 AS

T3_PEER_PROBABILITY Float The probability that a tier 3 AS brings up a peering class

BGP session with another tier 3 AS

DAEMON_PROBABILITY Float The probability that an AS should have an EWSD online e.g.

1.0 means full deployment

DAEMON_MAX_PEERS Integer 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 Con�guration

This section details how one can write their own topology in our chosen syntax. Topologies should be

written to the con�guration �le located at ews/con�g/topology.con�g relative to the distribution folder.

Declaring ASes

Description This command declares the range of ASNs to instantiate into the simulation. An AS will be

instantiated for each AS

Command as-init [from-ASN..to-ASN or ASN],......

Example as-init 65000..66000,900,905..909

Note This should be the �rst declaration within the con�guration

Declaring standard BGP router

Description This command declares a BGP router under some AS

Command router [IP] at-as [ASN]

Example router 160.10.0.1 at-as 65400

Making a router a route re�ector

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

re�ector

Command route-re�ector

Example router 160.10.0.1 at-as 65400

route-re�ector

8

Declaring a network

Description This command declares a network address for a BGP router to announce over BGP within the

simulation

Command network [CIDR IP]

Example 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

con�guration. 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 peer [declared BGP router IP of peer] [class COMMUNITY] [metric VALUE]

Example 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

Note Community tags must be declared within the con�guration �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 This command declares LOCAL-PREF �lters under a BGP router, this router will then apply

these �lters within its BGP simulation

Command local pref on all pre�xes heard from a neighboring AS

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

local pref on all pre�xes heard from a router at a neighboring AS

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

local pref on a particular pre�x heard from a neighboring AS

local-pref [value] pre�x [pre�x] next-hop-as [ASN]

local pref on a particular pre�x heard from a router at a neighboring AS

local-pref [value] pre�x [pre�x] next-hop [IP]

Example Example prefer a customer's routes over provider's except for a single pre�x

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 pre�x 23.0.0.0/8 next-hop 209.210.9.1

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.

9

Declaring MED �lters

Description This command declares MED �lters under a BGP router, this router will then apply these �lters

within its BGP simulation

Command 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 pre�x sent to a neighboring/peered AS

MED [value] on-pre�x [pre�x] to-as [ASN]

Set MED value for all routes for a particular pre�x sent to a neighboring/peered IP

MED [value] on-pre�x [pre�x] to-router [ASN]

Example Example, in�uence a neighboring AS,connected at two separate locations, to choose one

path/exit point over the other except for a particular pre�x

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-pre�x 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 This command declares �lters to ignore heard MED values under a BGP router, this router will

then apply these �lters within its BGP simulation

Command 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

MED ignore next-hop [IP]

Example 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

Note 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.

10

Declaring a routing policy

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

declaring peerings

Command policy [name] [shape (used for GraphViz rendering)]

no-ad [policy name]

Example 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

policy provider box

no-ad provider

no-ad peer

policy peer odot

no-ad provider

no-ad peer

policy customer box

policy None none

Note 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 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.

Command router [IP] at-as [ASN] daemon

Example router 160.10.0.1 at-as 65400 daemon

#BGP Interfaces

peer 160.10.0.2

peer 160.10.0.2

Note EWSD routers should be con�gured 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.

Declaring EWSD P2P Sessions

Description This command declares the initial P2P sessions (Report: section 5.2.1) that this EWSD should

attempt to bring up.

Command connect [EWSD IP]

Example router 160.10.0.1 at-as 65400 daemon

.....

connect 90.0.0.2

connect 191.9.0.1

Note 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

11

Declaring EWSD list of peers

Description This command declares/con�gures this EWSD with the ASNs of all ASes connected to the AS

running this EWSD.

Command as-peers [ASN:COMMUNITY TAG],...

Example 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

Note This is required to correctly detect indirect pre�x hijack attacks

Declaring EWSD atomicity list

Description This command declares/con�gures this EWSD with the set of pre�xes that are allowed to be

deaggregated i.e. should not warn on deaggregation attacks for them

Command deaggregated [CIDR IP],...

Example 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

Note This is required to correctly detect deaggregation pre�x hijacks

Declaring EWSD simulation suppression �lters

Description This command declares/con�gures the suppression �lters that should be used by EWSDs

within the simulation

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

Example suppression-modes 1,2

Note 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 con�guration

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 pre�x 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 pre�x 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-re�ector

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 con�gured, 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 port 50008,

this server is an interface from which simulation clients can access/manipulate the simulation (Report:

section 4).

6 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 di�erent views (graphical/text,

abstract/concrete)

Command global [-i] [-a] [-t pre�x] [-d]

-i: graphical view

-a: abstraction, i.e. the graphical view at AS granularity

-t: pre�x trace, overlays a graphical trace for a pre�x within the view

-d: Overlay P2P sessions within the view

Example # global

# global -i

# global -i -a -t 10.0.0.0/8

Note 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

14

View AS topology information

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

con�guration

Command as [ASN]

Example as 19282

View router information

Description 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 re�ector �ag, tells you if this router is actually a route re�ector

Command router [IP]

Example router 193.98.2.1

View EWSD information

Description This command allows you to view information speci�c 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 con�guration and attributes

Graphical representation of the EWSD's current graph of the Internet

Command daemon [IP] [-i] [-t pre�x]

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 pre�x, 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

Note 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

Live route withdrawal

Description This command allows you to withdraw a pre�x 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 e�ect it, the e�ects of the injection can then be seen with

the array of commands we previously detailed.

Command withdraw [pre�x] at [IP]

Example # 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 pre�x, into some router within the

topology. The simulation is live and hence injected routes should e�ect it, the e�ects of the

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

Command Injects a pre�x,with an empty AS-PATH, into some routers BGP table.

new-net [pre�x] at [IP]

Injects a pre�x,with a de�ned AS-PATH, into some routers BGP table. used mainly to perform

indirect pre�x hijacks.

mod-net [pre�x] [AS-PATH] at [IP]

Example # 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

Note 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.

7 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 documentation/

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

7.2 Analysis

Our analyzer/evaluator module, an automated client, is a wrapper for our simulation server. It invokes the

di�erent 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 ews/ folder

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

16

General attack detection

Description 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 general_attack_detection

Parameters modes

list of the attack types to simulate and gather data for

fanout

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)

Fixated attack detection

Description 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 �xated_attack_detection

Parameters modes

list of the attack types to simulate and gather data for

fanout

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)

Third party attack detection

Description 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 third_party_attack_detection

Parameters fanout

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)

17

Suppression bene�ts

Description 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 suppression_analysis

Parameters modes

list of the attack types to simulate and gather data for

fanout

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

General solution cost

Description 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 general_cost_detection

Parameters max_fanout

dictates the maximum FANOUT to analyze for message counts, i.e. analyze all the

topologies with FANOUT attribute less then this value

daemon_rate

The EWSD deployment percentage within the simulated topologies

Routing protocol overlay & SEQNO bene�ts

Description 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 overlay_seqno_cost_reduction

Parameters max_fanout

dictates the maximum FANOUT to analyze for message counts, i.e. analyze all the

topologies with FANOUT attribute less then this value

daemon_rate

The EWSD deployment percentage within the simulated topologies

18

8 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 Carries out automated analysis tests 922

Autonomous.py Contains description of a AS within the simulation 58

BGP.py Contains description of BGP operation within the simulation 370

BGP_Structures.py Contains support structures for BGP simulation 171

Client

Node.py Simulation client 72

Con�guration.py Initializes/Manipulates/Queries the simulation topology 715

Daemon

Crypter.py Cryptographic component of the daemon solution 117

Daemon.py Contains the description of the EWSD main controller component 518

Graph.py Graph component of the daemon solution 405

Protocols

PVP.py Contains path vector implementation of our overlay protocol 193

DVP.py Contains distance vector implementation of our overlay protocol 90

LSP.py Contains link state implementation of our overlay protocol 91

Structures.py Contains support structures for Early waning system components 143

Generator.py Generates topologies 353

Globals.py Holds variables global to the simulation 67

Printer.py Contains (graphical/text) output generating functions 497

Pro�le.py Code performance pro�le viewer 15

Router.py Contains description of a router within the simulation 166

Statistics.py Contains live logging functionality 93

Simulator.py Simulation server 162

In summary, we have included approximately we have listed approximately 25% of our code base, our

listings re�ect the segments of code that we believe to be interesting. Our listings omit a vast amount

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

19

8.3 Attacker.py code listing

For this module we will list one of the automated analysis methods (�xated_attack_analysis()) we

have implemented and part of the draw() method which displays the results of this analysis. We have

only included a single example because we feel that it is su�cient to show how we have wrapped our

simulators code to automate our analysis.

Listed : 20% of module code

160 def f i xated_attack_detect ion (modes , fanout , seeded ) :

161 """

162 Schedules s imu la t i on s and i n j e c t s BGP at tacks with in them , i t then c o l l e c t s r e s u l t s aimed at

163 f i nd i n g the c o r e l a t i o n between the amount ( percentage ) o f EWSD' s running and the perecentage

164 o f a t tack s EACH EWSD can det e c t aga in s t i t .

165 @param modes : L{ l i s t } o f the attack types to s imulate and gather data f o r

166 @param fanout : The fanout a t t r i b u t e to i n s t a n t i s a t e the automated topology generato r with

167 @param seeded : I nd i c a t e s i f the EWSD deployment and growth should be seeded or not

168 """

169 import Simulator , Generator , Globals , S t a t i s t i c s , Conf igurat ion , Daemon

170 # Topolog ies generated under t h i s t e s t w i l l be s to r ed in some random f i l e

171 f i l e n o = s t r ( i n t ( random ()∗100000) )172 # In s t a n t i a t e the v a r i a b l e s that w i l l hold the r e s u l t s o f t h i s t e s t

173 for mode in modes :

174 FIXATED_DETECTION[mode ] = { 0 : [ 0 , 0 , 0 ] , 1 : [ 0 , 1 , 0 ] }

175 DETECTION_TIER_DIST[ 'T1 ' ] [ mode ] = [ ]

176 DETECTION_TIER_DIST[ 'T2 ' ] [ mode ] = [ ]

177 DETECTION_TIER_DIST[ 'T3 ' ] [ mode ] = [ ]

178 # Generate an i n i t i a l topology , to be used by the t e s t runs

179 Generator . c l ean_state ( )

180 Generator .CONFIG = {"FANOUT" : fanout ,

181 "ROUTERS_PER_AS" : 1 ,

182 "T2_PEER_PROBABILITY" : 0 . 6 ,

183 "T3_PEER_PROBABILITY" : 0 . 3 ,

184 "DAEMON_PROBABILITY" : 0 , # I n i t i a l l y no EWSD' s running

185 "DAEMON_MAX_PEERS" :5}

186 Generator . generate ( seeded , f i l e n o , True )

187 # Run the t e s t f o r deployment l e v e l s between 0−100% in s t ep s o f 10%

188 for i in range ( 0 , 1 0 ) :

189 i += 1

190 Simulator . c l ean_state ( )

191 i f seeded :

192 # Seeded t opo l o g i e s grow around the seed , the genera to r has a s p e c i a l f unc t i on f o r t h i s

193 Generator . increase_seed_radius ( f i l e n o , i /10 .0 , True )

194 else :

195 # I f i t s not seeded then j u s t generate a new random topology

196 Generator . c l ean_state ( )

197 Generator .CONFIG = {"FANOUT" : fanout ,

198 "ROUTERS_PER_AS" : 1 ,

199 "T2_PEER_PROBABILITY" : 0 . 6 ,

200 "T3_PEER_PROBABILITY" : 0 . 3 ,

201 "DAEMON_PROBABILITY" : i /10 .0 ,

202 "DAEMON_MAX_PEERS" :5}

203 Generator . generate ( seeded , f i l e n o , True )

204 # Run each type o f at tack with t h i s topo logy

205 for mode in modes :

206 # Clean the s imu lag to r s prev ious s tate , then re l oad / load the topology to be t e s t ed

207 Simulator . c l ean_state ( )

208 Conf igurat ion . load_topology ( " c on f i g /"+f i l e n o )

20

209 command = Conf igurat ion . process_command

210 # L i s t o f r ou t e r s with in the topology not running an EWSD and not route r e f l e c t o r s

211 r ou t e r s = [ ( ip , ob j e c t . as_number ) for ( ip , ob j e c t ) in Globals .ROUTERS. items ( ) i f \

212 not ob j e c t . running_daemon and not ob j e c t . r ou t e_r e f l e c t o r ]

213 # L i s t o f ASes with in t h i s topo logy that are running EWSD' s

214 daemonised_ases = [ ob j e c t . as_number for ( ip , ob j e c t ) in Globals .ROUTERS. items ( ) i f \

215 ob j e c t . running_daemon ]

216 i f l en ( daemonised_ases ) <= 1 :

217 continue

218 daemon_p = S t a t i s t i c s .DAEMON_COUNT∗100/ l en ( Globals .ASES)

219 #Average de t e c t i on , Highest Detect ion , Lowest Detect ion f o r t h i s at tack type with

220 #th i s deployment l e v e l

221 FIXATED_DETECTION[mode ] [ daemon_p ] = [ 0 , 0 , f l o a t ( ' i n f ' ) ]

222 x = 0

223 lowest_undetected = [ ]

224 # attack each AS running an EWSD by a l l other ASes

225 for victim_as in daemonised_ases :

226 x+=1

227 Simulator . c l ean_state ( )

228 Conf igurat ion . load_topology ( " c on f i g /"+f i l e n o )

229 # Choose a route r that should announce th ings at the v ic t im

230 for victim_ip , router_object in Globals .ASES [ victim_as ] . r ou t e r s . i tems ( ) :

231 i f not ob j e c t . running_daemon and not ob j e c t . r ou t e_r e f l e c t o r :

232 break

233 # Schedule the v ic t im route r to announce some p r e f i x

234 st ime = Globals .TIME + 5

235 add_event ( st ime+20,command , "new−net "+vict im_ip+"/8 at "+vict im_ip )

236 st ime += 20

237 h i t = [ ]

238 # again g ive each attack 2 chances to be captured by a daemons p e r i o d i c CRA f l o od

239 attack_length = 2∗Daemon .Daemon .ASSERTION_RATE + 5

240 for ( attacker_ip , attacker_as ) in r ou t e r s :

241 i f attacker_as in h i t : continue

242 else : h i t . append ( attacker_as )

243 i f attacker_as == victim_as : continue

244 # Each AS with in the topology w i l l a t tack t h i s AS running an EWSD

245 i f mode == "DIRECT" :

246 S t a t i s t i c s .ATTACKS[ ( vict im_ip+"/8" , s t r ( attacker_as ) ) ] = Fal se

247 add_event ( stime , command , "new−net "+vict im_ip+"/8 at "+attacker_ip )

248 add_event ( st ime+attack_length , command , "withdraw "+vict im_ip+"/8 at "\

249 +attacker_ip )

250 i f mode == "INDIRECT" :

251 sk ip = False

252 # i f the re a l r eady connected then you i t s not an i n d i r e c t attack

253 i f s t r ( attacker_as ) in Generator . as_peers [ s t r ( victim_as ) ] :

254 sk ip = True

255 S t a t i s t i c s .ATTACKS[ ( vict im_ip+"/8" , s t r ( attacker_as ) ) ] = sk ip

256 add_event ( stime , command , "mod−net "+vict im_ip+"/8 "+s t r ( victim_as)+\

257 " at "+attacker_ip )

258 add_event ( st ime+attack_length , command , "withdraw "+vict im_ip+"/8 at "\

259 +attacker_ip )

260 i f mode == "DEAGGREGATION" :

261 S t a t i s t i c s .ATTACKS[ ( vict im_ip+"/8" , s t r ( attacker_as ) ) ] = Fal se

262 add_event ( stime , command , "new−net "+vict im_ip+"/16 at "+attacker_ip )

263 add_event ( st ime+attack_length , command , "withdraw "+vict im_ip+"/16 at "\

264 +attacker_ip )

265 st ime += attack_length + 5

266 # Attacks have now a l l been scheaduled , s t a r t t h i s s imu la to r

267 print ' S t a r t i ng f i x a t e d attack run ' ,mode , ' a t tacks ' , l en ( S t a t i s t i c s .ATTACKS) ,\

21

268 ' a t tacks scheduled '

269 print 'P(Daemon) ' , i /10 .0

270 print ' V ic t imised ' , x , ' / ' , l en ( daemonised_ases )

271 print ' Seeded ' , seeded

272 print ' Expected f i n i s h time ' , st ime

273 # Star t the s imu la t i on

274 Simulator . s t a r t ( False , stime , run )

275 # Simulat ion has ended , now c o l l e c t r e s u l t s r egard ing attack de t e c t i on

276 to ta l_at tacks = len ( S t a t i s t i c s .ATTACKS)

277 found_n = len ( [ True for attack , found in S t a t i s t i c s .ATTACKS. items ( ) i f found ] )

278

279 found_p = in t ( found_n∗100/ to ta l_at tacks )

280 # Sum a l l the de t e c t i on r a t e s undet h i s mode and deployment . l a t e r averaged

281 FIXATED_DETECTION[mode ] [ daemon_p ] [ 0 ] += found_p

282 # i s t h i s the h i ghe s t d e t e c t i on under t h i s mode and deployment ?

283 i f found_p > FIXATED_DETECTION[mode ] [ daemon_p ] [ 1 ] :

284 FIXATED_DETECTION[mode ] [ daemon_p ] [ 1 ] = found_p

285 # i s t h i s the lowest d e r e c t i on under t h i s mode and deployment ?

286 i f found_p < FIXATED_DETECTION[mode ] [ daemon_p ] [ 2 ] :

287 FIXATED_DETECTION[mode ] [ daemon_p ] [ 2 ] = found_p

288 lowest_undetected = [ attack for attack , found in S t a t i s t i c s .ATTACKS. items ( ) \

289 i f not found ]

290 # Log t h i s d e t e c t i on ra t e under the approp iate AS t i e r the v ic t im belonged to

291 i f s t r ( victim_as ) in Generator .T1 :

292 DETECTION_TIER_DIST[ 'T1 ' ] [ mode ] . append ( found_p )

293 i f s t r ( victim_as ) in Generator .T2 :

294 DETECTION_TIER_DIST[ 'T2 ' ] [ mode ] . append ( found_p )

295 i f s t r ( victim_as ) in Generator .T3 :

296 DETECTION_TIER_DIST[ 'T3 ' ] [ mode ] . append ( found_p )

297 # Clean up the s to r ed r e s u l t s , c a l c u l a t e everages , h i ghe s t and lowest are no d i f f r e n c e s

298 # from the average

299 FIXATED_DETECTION[mode ] [ daemon_p ] [ 0 ] /= f l o a t ( l en ( daemonised_ases ) )

300 FIXATED_DETECTION[mode ] [ daemon_p ] [ 1 ] −= FIXATED_DETECTION[mode ] [ daemon_p ] [ 0 ]

301 FIXATED_DETECTION[mode ] [ daemon_p ] [ 2 ] = FIXATED_DETECTION[mode ] [ daemon_p ] [ 0 ] − \

302 FIXATED_DETECTION[mode ] [ daemon_p ] [ 2 ]

303 # I f the re i s a var i ance in de t e c t i on rate s , i . e . a t tacks were un detected , then s t o r e

304 # the topology and detec ted at tacks f o r manual rev iew

305 i f l en ( lowest_undetected ) != 0 :

306 In = open ( " c on f i g /"+f i l e n o ) # use raw s t r i n g s f o r windows f i l e names

307 Out = open ( " c on f i g / f i x a t e d /"+mode+"/"+s t r (daemon_p)+"−topo logy . c on f i g " , "w" )

308 for l i n e in In :

309 Out . wr i t e ( l i n e )

310 Out . c l o s e ( )

311 Out = open ( " c on f i g / f i x a t e d /"+mode+"/"+s t r (daemon_p)+"− f a i l i u r e . c on f i g " , "w" )

312 for ip , source in lowest_undetected :

313 Out . wr i t e ( "Target : "+ip+" Source : "+source+"\n" )

314 In . c l o s e ( )

315 Out . c l o s e ( )

732 def draw ( )

733 . . . . . . . . . . . . . . . . . . . .

734 i f l en (FIXATED_DETECTION) != 0 :

735 p l o t . f i g u r e (2 )

736 handles , l a b e l s = [ ] , [ ]

737 o f f s e t = 0

738 s t y l e = [ ' ro− ' , ' go− ' , ' bo− ' ]

739 for type , entry in FIXATED_DETECTION. items ( ) :

740 x , y = make( entry , 0 , o f f s e t )

741 xerr , yposer r = make( entry , 1 )

22

742 xerr , ynegerr = make( entry , 2 )

743 s = s t y l e . pop ( )

744 l i n e = p lo t . p l o t (x , y , s )

745 p l o t . e r r o rba r (x , y , ye r r =[ ynegerr , yposer r ] , fmt=s )

746 handles . append ( l i n e )

747 l a b e l s . append ( type )

748 o f f s e t += 1

749 p lo t . x l ab e l ( '% Daemons ' )

750 p l o t . y l ab e l ( '% Attacks Detected ' )

751 p l o t . f i g l e g e nd ( tup l e ( handles ) , tup l e ( l a b e l s ) , ' upper r i g h t ' )

752 p l o t . t i t l e ( "Detect ion ra t e o f a t tacks f i x a t e d on a s i n g l e t a r g e t " )

753 p l o t . f i g u r e (3 )

754 handles , l a b e l s = [ ] , [ ]

755 x = 1

756

757 for t i e r , entry in DETECTION_TIER_DIST. items ( ) :

758 co l ou r s = [ 'magenta ' , ' cyan ' , ' ye l low ' ]

759 for type , va lue s in entry . i tems ( ) :

760 y = f l o a t (sum( va lues ) )/ l en ( va lue s )

761 dot = p lo t . s c a t t e r (x , y , c=co l ou r s . pop ( ) )

762 i f type not in l a b e l s :

763 handles . append ( dot )

764 l a b e l s . append ( type )

765 p l o t . annotate ( t i e r , xy=(x , 2 ) , xytext=(x , 2 ) )

766 x+=1

767 p lo t . yl im ( [ 0 , 1 0 1 ] )

768 p l o t . y l ab e l ( ' Average Detect ion %' )

769 p l o t . f i g l e g e nd ( tup l e ( handles ) , tup l e ( l a b e l s ) , ' upper r i g h t ' )

770 p l o t . t i t l e ( "Tier d e t e c t i on " )

771 . . . . . . . . .

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

Listed: 100% of module code

13 class BGP:

14 """

15 This i s a c l a s s d e s c r i p t i o n r ep r e s en t i ng BGP on a route r , as such i t i s

16 encapsu lated by L{Router} c l a s s that c a l l s on i t to s imulate i t . Furthermore t h i s c l a s s

17 encapsu l a t e s L{BGP_Session} ob j e c t s that r ep r e s en t and s imu la t e s BGP s e s s i o n s between

18 the route r that encapsu l a t e s t h i s BGP ob j e c t and on o f i t s pee r s

19 @ivar route r : L{Router} ob j e c t t h i s BGP i s running on

20 @ivar s e s s i o n s : L{map} o f a l l L{BGP_Sessions} to the IP address o f the route r at other

21 s e s s i o n end

22 @ivar t ab l e : L{BGP_Table} ob j e c t o f t h i s r ou t e r s BGP RIB

23 """

24 def __init__( s e l f , r ou t e r ) :

25 """

26 con s t ruc to r f o r BGP ob j e c t

27 @param route r : the route r t h i s BGP i s running on

28 """

29 s e l f . r ou t e r = route r

30 s e l f . s e s s i o n s = {} # Se s s i on s handled by t h i s BGP ob j e c t

31 s e l f . t ab l e = BGP_Table ( ) # RIB For the route r

23

32

33 def s t a r t_s e s s i o n s ( s e l f ) :

34 """

35 Creates BGP s e s s i o n s f o r a l l v a l i d pee r ing r e l a t i o n s h i p s , s e s s i o n s are c r ea ted

36 once and the same s e s s i o n w i l l s tay up t i l l i t s bought down by e i t h e r end o f the peer .

37 This i s c a l l e d by the con f i gu ra ton module once a l l r ou t e r s are i n i t

38 """

39 for ( peer_router_number , peer_router ) in s e l f . r ou t e r . pee r s . i tems ( ) :

40 # i f a s e s s i o n a l r eady e x i s t s f o r t h i s s p e c i f i c peer or t h i s peer does not want

41 # to accept our s e s s i o n then do not br ing up a s e s s i o n

42 i f peer_router_number in s e l f . s e s s i o n s or not peer_router . accept_router ( s e l f . r ou t e r ) :

43 continue

44 ibgp = True i f peer_router . as_number == s e l f . r ou t e r . as_number else False

45 s e s s i o n = BGP_Session ( s e l f . router , peer_router , ibgp )

46 # add the s e s s i o n to t h i s BGP pro toco l and to the peer t a r g e t BGP pro to co l

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

48 peer_router . accept_ses s ion ( s e l f . router , s e s s i o n )

49 ' ' '

50 s e l f . r ou t e r . l og . append ("BGP s e s s i o n : "+peer_router . number+" AS "+\

51 s t r ( peer_router . as_number ) + " iBGP = " +s t r ( ibgp ) )

52 peer_router . l og . append ("BGP s e s s i o n : "+ s e l f . r ou t e r . number+" AS "+\

53 s t r ( s e l f . r ou t e r . as_number ) + " iBGP = " +s t r ( ibgp ) )

54 ' ' '

55

56 def s imulate ( s e l f ) :

57 """

58 Method used to command t h i s BGP pro to co l to run a s i n g l e s imu la t i on step , t h i s c o n s i s t s o f

59 sending a l l changes to the RIB and r e c i v i n g and pro c e s s i ng a l l messages sent on Se s s i on s

60 @return In t eg e r : number o f new route s l ea rned

61 """

62 # I f the re are changes to the RIB command a l l s e s s i o n s to transmit them then c l e a r them

63 s e s s i o n s = s e l f . s e s s i o n s

64 i f l en ( s e l f . t ab l e . changes ) > 0 :

65 # Daemons run modi f i ed BGP , they dont sent rout ing i n f o , only l i s t e n

66 i f not s e l f . r ou t e r . running_daemon :

67 for ip in s e s s i o n s :

68 s e s s i o n s [ ip ] . send ( s e l f . router , s e l f . t ab l e )

69 s e l f . t ab l e . delete_change ( )

70

71 new_routes_count = 0

72 # Command a l l s e s s i o n s to r e c ev i v e and proce s s any BGP messages r e c ev i ed

73 for ip in s e s s i o n s :

74 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 . t ab l e )

75 new_routes_count += count

76 return new_routes_count

77

78 class BGP_Session :

79 """

80 BGP Ses s i on c l a s s ob j e c t , t h i s ob j e c t r ep r e s en t s a BGP s e s s i o n running between two rou t e r s

81 whom have s u c e s s f u l l y peered . i t handles sending and r e c i v i n g messages on bother r ou t e r s who

82 s t a r t ed t h i s s e s s i o n

83 @ivar peer_a : L{Router} at end A of the l i n k

84 @ivar peer_b : L{Router} at end B o f the l i n k

85 @ivar peer_a_que : Queue (L{ l i s t }) f o r route r at end A o f the l i n k

86 @ivar peer_b_que : Queue (L{ l i s t }) f o r route r at end B o f the l i n k

87 @ivar ibgp : i n d i c a t o r i f t h i s s e s s i o n i s an iBGP s e s s i o n

88 """

89 def __init__( s e l f , peer_a , peer_b , ibgp_peer ) :

90 s e l f . peer_a = peer_a

24

91 s e l f . peer_b = peer_b

92 s e l f . peer_a_que = [ ]

93 s e l f . peer_b_que = [ ]

94 s e l f . ibgp = ibgp_peer

95

96 def send ( s e l f , sender , senders_table ) :

97 """

98 Cal led when changes to the RIB at the one end are detec ted , i t makes

99 UPDATE messages to no t i f y other end o f l i n k o f the se changes and p l a c e s

100 them in the ends queue

101 @param sender : L{Router} ob j e c t o f the route r sending changes

102 @param senders_table : L{BGP_Table}(BGP RIB) o f the route r sending changes

103 """

104 messages = [ ]

105 withdrawn = [ ]

106 # we must f i g u r e out what s i d e o f the l i n k the r e c i v e r i s on so we know who i s r e c i v i n g and

107 # the queue to put the messages in

108 target_que = s e l f . peer_b_que i f sender . number == s e l f . peer_a . number else s e l f . peer_a_que

109 r e c i v e r = s e l f . peer_b i f sender . number == s e l f . peer_a . number else s e l f . peer_a

110

111 # For every p r e f i x that has changed in our t ab l e , send a l l the new/changed route s heard

112 # f o r that p r e f i x or withdraw i f i f i t i s no l onge r in our t ab l e

113 for p r e f i x in senders_table . changes :

114 # p r e f i x does not e x i s t anymore than t h i s f l a g was to i nd i c a t e a complete withdrawal

115 i f not senders_table . has_entry ( p r e f i x ) :

116 withdrawn . append ( p r e f i x )

117 continue

118 entry = senders_table . get ( p r e f i x )

119 # Attempt to send a l l the changed route s under the changed p r e f i x

120 for route_number in entry . changes :

121 # i f t h i s route does not e x i s t anymore than t h i s entry f l a g i s to i nd i c a t e a route

122 # withdrawal ( prev ious best route )

123 i f route_number not in entry . route s :

124 withdrawn . append ( p r e f i x )

125 continue

126

127 route = entry . get_route ( route_number )

128 # i f we are sending to a c l a s s e d l ink , only send route i f our po l i c y permits

129 i f route [CONFEDERATION_LOC] != None and \

130 sender . peer_c las s [ r e c i v e r . number ] in Globals . POLICIES [ route [CONFEDERATION_LOC] ] :

131 continue

132 # Dont transmit t h i s p r e f i x i f we heard i t from the route r were sending to now

133 i f route [HEARD_FROM_LOC] == r e c i v e r . number : continue

134 # Dont transmit route s heard from ibgp over ibgp except i f the sender i s a RR

135 i f route [HEARD_FROM_IBGP_LOC] and s e l f . ibgp and not sender . r ou t e_r e f l e c t o r : continue

136

137 o r i g i n = route [ORIGIN_LOC]

138 i f not s e l f . ibgp :

139 # Sending to iBGP , attach your ASN , MED , c l e a r a t t r i b u t e s t r a n s i t i v e over

140 # iBGP only

141 as_path = s t r ( sender . as_number)+ ' '+route [AS_PATH_LOC]

142 next_hop = sender . number

143 next_hop_as = sender . as_number

144 med = s e l f . get_med( p r e f i x , sender , r e c i v e r )

145 l o ca l_pr e f = 0

146 igp_dist = 0

147 con f ede ra t i on = None

148 else :

149 # I f were sending over iBGP then pre s e rve a t t r i b u t e s , save the iBGP metr ic

25

150 # that should be changed

151 as_path = route [AS_PATH_LOC]

152 next_hop = route [NEXT_HOP_LOC]

153 next_hop_as = route [NEXT_HOP_AS_LOC]

154 med = route [MED_LOC]

155 l o ca l_pr e f = route [LOCAL_PREF_LOC]

156 igp_dist = route [IGP_DIST_LOC] + sender . peer_metric [ r e c i v e r . number ]

157 con f ede ra t i on = route [CONFEDERATION_LOC]

158

159 added_flag = False

160 # add p r e f i x to n l r i o f a p r ev i ou s l y c rea ted message with same route a t t r i b u t e s

161 for message in messages :

162 i f message . accept_pre f ix ( p r e f i x , o r i g i n , as_path , next_hop , \

163 next_hop_as ,med , l oca l_pre f , igp_dist , c on f ede ra t i on ) :

164 added_flag = True

165 break

166 # i f p r e f i x could not be added to any message then add i t to a new one with

167 # the p r e f i x ' s route a t t r i b u t e s

168 i f not added_flag :

169 messages . append (Update ( p r e f i x , o r i g i n , as_path , next_hop , next_hop_as , \

170 med , l oca l_pre f , igp_dist , c on f ede ra t i on ) )

171 # i f no messages e x i s t we c r ea t e a dummy message to hold the withdrawals

172 i f l en ( messages ) == 0 and l en ( withdrawn ) > 0 :

173 path = s t r ( sender . as_number )

174 i f s e l f . ibgp : path = ' '

175 messages . append (Update ( ' ' , ' ' , path , ' ' , ' ' , ' ' , ' ' , ' ' ,None ) )

176 # Choose any message to put any withdrawals we have in them

177 i f l en ( withdrawn ) > 0 : cho i c e ( messages ) . withdrawn = withdrawn

178 # Add a l l messages to the queue o f the r e c e i v e r at the other end o f the s e s s i o n

179 for message in messages : target_que . append (message )

180 del messages [ : ]

181

182

183 def r e c e i v e ( s e l f , r e c i v e r , r e c i v e r_tab l e ) :

184 """

185 Used to r e c e i v e BGP messages v ia t h i s BGP s e s s i o n on one end , messages are proce s sed

186 from the r e c e i v e r s queue

187 @param r e c e i v e r : L{Router} ob j e c t o f the route r r e c i v i n g on t h i s s e s s i o n

188 @param rec e i v e r_tab l e : L{BGP_Table}(BGP RIB) to update with the r e c e i v ed BGP updates

189 """

190 ## WE COULD ju s t a c c e s s the RIB though the route r ob j e c t but that long ( route r . bgp . t ab l e )

191 # determine what queue be longs to the r e c i v i n g end

192 input_que = s e l f . peer_a_que i f r e c i v e r . number == s e l f . peer_a . number else s e l f . peer_b_que

193 sender = s e l f . peer_b i f r e c i v e r . number == s e l f . peer_a . number else s e l f . peer_a

194

195 new_routes_count = 0

196 # Process each message

197 for message in input_que :

198 new_routes_count += s e l f . process_update_message (message , r e c i v e r , sender , r e c i v e r_tab l e )

199 del input_que [ : ]

200 return new_routes_count

201

202 def process_update_message ( s e l f , message , r e c i v e r , sender , r e c i v e r_tab l e ) :

203 """

204 Process an update message that has been read from the r e c e i v e r s queue , makes approp iate

205 changes to the r e c i v e r s BGP RIB based on BGP route s e l e c t i o n and po l i c y based rout ing

206 @param message : Update message L{Update}

207 @param r e c i v e r : L{Router} ob j e c t f o r the r e c i v i n g end o f the s e s s i o n

208 @param sender : L{Router} ob j e c t f o r the end that sent t h i s message

26

209 @param rec i v e r_tab l e : L{BGP_Table}(BGP RIB) to update with t h i s message

210 """

211 # Dont con s id e r route s that have your ASN in them

212 i f s t r ( r e c i v e r . as_number ) in message . as_path . s p l i t ( ) : return 0

213 # Modify the MED a t t r i bu t e with in the message based on the r e c e i v e r s f i l t e r s

214 message = s e l f . apply_med_fi lter (message , r e c i v e r )

215 # Speed Mods

216 get_loca l_pre f = s e l f . get_loca l_pre f

217 table_has_entry = re c i v e r_tab l e . has_entry

218 # Handle a l l withdrawn p r e f i x e s

219 for p r e f i x in message . withdrawn :

220 i f table_has_entry ( p r e f i x ) :

221 entry = re c i v e r_tab l e . get ( p r e f i x )

222 remove_id = None

223 # Remove a l l r oute s under t h i s withdrawn p r e f i x heard from the sender o f

224 # the message ( can only be one due to imp l i c i t r ep l a c e in BGP_Table_Entry)

225 for id , route in entry . route s . i tems ( ) :

226 i f route [HEARD_FROM_LOC] == sender . number :

227 del entry . route s [ id ]

228 remove_id = id

229 break

230 i f l en ( entry . r oute s ) > 0 :

231 # Run knock out a l go r i th im to see who i s the cur rent winner a f t e r the withdrawl

232 # then command the tab l e to check i f the re i s changes to t h i s entry , the re w i l l

233 # de f i n a t e l y be a change i f remove_id was our best route ,

234 # on send i f a route i s not found but marked as changed i t i s assumed withdrawn

235 i f entry . best_route_number == remove_id : entry . changes . append ( remove_id )

236 s e l f . knockout ( entry )

237 r e c i v e r_tab l e . check_change ( p r e f i x )

238 else :

239 # a l t e r n a t i v e l y i f no route s are l e f t then remove the p r e f i x a l t o g e t h e r

240 # and j u s t t e l l the t ab l e that the p r e f i x has changed , on send i f the p r e f i x i s

241 # not found and marked as changed i t i s assumed as withdrawn

242 del r e c i v e r_tab l e . ent rys [ p r e f i x ]

243 r e c i v e r_tab l e . changes . append ( p r e f i x )

244

245 # Handle a l l announced p r e f i x e s in the Update message

246 for p r e f i x in message . n l r i :

247 # apply l o c a l p r e f f i l t e r s and d i s c ove r the l o c a l p r e f va lue f o r t h i s route

248 pr e f i x_ loca l_pre f = get_loca l_pre f (message , p r e f i x , r e c i v e r )

249 i f not table_has_entry ( p r e f i x ) : r e c i v e r_tab l e . add (BGP_Table_Entry( p r e f i x ) )

250 # CONFEDERATION IS COMMUNITY −−−−−−−−− MADEE THE MISTAK EARLY ON −−−− TO LONG TO CHANGE

251 entry = re c i v e r_tab l e . get ( p r e f i x )

252 # the con f ede ra t i on tag i s what our ibgp peer s p e c i f i e d , i f not an ibgp peer or

253 # un sp e c i f i e d , then use the con f ede ra t i on tag o f the pee r ing r e l a t i o n s h i p

254 confed = message . c on f ede ra t i on i f ( s e l f . ibgp and message . c on f ede ra t i on != None )\

255 else r e c i v e r . peer_c las s [ sender . number ]

256 # add t h i s route as a new route f o r the p r e f i x , or the route w i l l im p l i c i t l y r ep l a c e

257 # prev ious route though i n t e r n a l operat i on o f the BGP tab l e

258 entry . add_route ( message . o r i g i n , message . as_path , message . next_hop , message . next_hop_as , \

259 message .med , pre f i x_loca l_pre f , sender . number , s e l f . ibgp , confed , \

260 message . igp_dist )

261 # Run knock out a l go r i th im to see who i s the cur rent winner a f t e r t h i s new announcment

262 s e l f . knockout ( entry )

263 r e c i v e r_tab l e . check_change ( p r e f i x )

264 return l en ( message . n l r i ) + l en ( message . withdrawn )

265

266 def knockout ( s e l f , entry ) :

267 """

27

268 Runs Knock out a l go r i th im on a RIB p r e f i x entry that i d e n t i f i e s the best

269 route the entry ho lds f o r the p r e f i x , the best route i s then marked in the l i s t

270 o f changes o f that entry so i t could be sent out

271 @param param entry : L{BGP_Table_Entry} o f the tab l e to run the K.O algo on

272 """

273

274 route_numbers = copy ( entry . route s . keys ( ) )

275 get_route = entry . get_route

276 pop = route_numbers . pop

277 while l en ( route_numbers ) > 1 :

278 """

279 Knock out a l go r i th im that c on t i nua l l y compares f i r s t two elements o f the route_numbers

280 l i s t , to compare the e lements the route s with route numbers corrosponding to the re va lue s are

281 r e t r i v e d and BGP route s e l e c t i o n compar is ion i s app l i ed . loop breaks when route_number has 1

282 item (Winner )

283 """

284 route_a = get_route ( route_numbers [ 0 ] )

285 route_a_as_count = len ( route_a [AS_PATH_LOC] . s p l i t ( ) )

286 route_b = get_route ( route_numbers [ 1 ] )

287 route_b_as_count = len ( route_b [AS_PATH_LOC] . s p l i t ( ) )

288

289 # Highest LOCAL−PREF290 i f route_a [LOCAL_PREF_LOC] != route_b [LOCAL_PREF_LOC] :

291 i f route_a [LOCAL_PREF_LOC] < route_b [LOCAL_PREF_LOC] : pop (0 )

292 else : pop (1 )

293 # Then sho r t e s t AS−PATH294 e l i f route_a_as_count != route_b_as_count :

295 i f route_a_as_count > route_b_as_count : pop (0 )

296 else : pop (1 )

297 # Then Lowest MED

298 e l i f route_a [MED_LOC] != None and route_b [MED_LOC] != None and \

299 route_a [NEXT_HOP_AS_LOC] == route_b [NEXT_HOP_AS_LOC] and \

300 route_a [MED_LOC] != route_b [MED_LOC] :

301 i f route_a [MED_LOC] > route_b [MED_LOC] : pop (0 )

302 else : pop (1 )

303 # eBGP over iBGP

304 e l i f route_a [HEARD_FROM_IBGP_LOC] != route_b [HEARD_FROM_IBGP_LOC] :

305 i f route_a [HEARD_FROM_IBGP_LOC] : pop (0 )

306 else : pop (1 )

307 # Lowest IGP metr ic

308 e l i f route_a [IGP_DIST_LOC] != route_b [IGP_DIST_LOC] :

309 i f route_a [IGP_DIST_LOC] > route_b [IGP_DIST_LOC] : pop (0)

310 else : pop (1 )

311 # Tie Breaker

312 else :

313 i f i n t ( ' ' . j o i n ( route_a [NEXT_HOP_LOC] . r s p l i t ( ' . ' ) ) ) > \

314 i n t ( ' ' . j o i n ( route_b [NEXT_HOP_LOC] . r s p l i t ( ' . ' ) ) ) : pop (0 )

315 else : pop (1 )

316 best_route_number = pop ( )

317 # i f the winner i s a d i f f r e n t route to the prev ious best route then add i t to

318 # p r e f i x entry change

319 i f best_route_number != entry . best_route_number :

320 i f best_route_number not in entry . changes : entry . changes . append ( best_route_number )

321 entry . best_route_number = best_route_number

322

323 def get_loca l_pre f ( s e l f , message , p r e f i x , r e c i v e r ) :

324 """

325 Used to re turn the LOCAL−PREF value f o r a p r e f i x with in a r e c i v ed BGP update message

326 @param message : BGP L{Update} message

28

327 @param p r e f i x : s p e c i f i c p r e f i x with in the message

328 @param r e c i v e r : the L{Router} ob j e c t o f the route r r e c i v i n g / c a l c u l a t i n g l o c a l−pr e f

329 """

330 i f s e l f . ibgp :

331 return message . l o ca l_pr e f

332 e l i f ( p r e f i x , message . next_hop ) in r e c i v e r . l o c a l_pr e f_pr e f i x_rou t e r_ f i l t e r :

333 return r e c i v e r . l o c a l_pr e f_pr e f i x_rou t e r_ f i l t e r [ ( p r e f i x , message . next_hop ) ]

334 e l i f ( p r e f i x , message . next_hop_as ) in r e c i v e r . l o c a l_pr e f_pr e f i x_as_f i l t e r :

335 return r e c i v e r . l o c a l_pr e f_pr e f i x_as_f i l t e r [ ( p r e f i x , message . next_hop_as ) ]

336 e l i f message . next_hop in r e c i v e r . l o c a l_p r e f_rou t e r_ f i l t e r :

337 return r e c i v e r . l o c a l_p r e f_rou t e r_ f i l t e r [ message . next_hop ]

338 e l i f message . next_hop_as in r e c i v e r . l o c a l_pr e f_a s_ f i l t e r :

339 return r e c i v e r . l o c a l_pr e f_a s_ f i l t e r [ message . next_hop_as ]

340 # ju s t so i dont con fuse mysel f , i could j u s t re turn message . l o ca l_pr e f to the same e f f e c t ,

341 # becuase when sending l o ca l_pr e f i s c l e a r ed except i f were sending over IBGP

342 return 0

343

344 def get_med( s e l f , p r e f i x , sender , r e c i v e r ) :

345 """

346 Used to re turn the MED value f o r a p r e f i x we are about to send to <sender>

347 @param p r e f i x : the p r e f i x to c a l c u l a t e the MED fo r

348 @param r e c i v e r : the L{Router} ob j e c t o f the route r that w i l l r e c i e v e t h i s MED

349 @param sender : the L{Router} ob j e c t o f the route r that i s sending t h i s message

350 """

351 i f ( p r e f i x , r e c i v e r . number ) in sender . MED_prefix_router_fi lter :

352 return sender . MED_prefix_router_fi lter [ ( p r e f i x , r e c i v e r . number ) ]

353 e l i f ( p r e f i x , r e c i v e r . as_number ) in sender . MED_prefix_as_filter :

354 return sender . MED_prefix_as_filter [ ( p r e f i x , r e c i v e r . as_number ) ]

355 e l i f r e c i v e r . number in sender . MED_router_filter :

356 return sender . MED_router_filter [ r e c i v e r . number ]

357 e l i f r e c i v e r . as_number in sender . MED_as_filter :

358 return sender . MED_as_filter [ r e c i v e r . as_number ]

359 return None

360

361 def apply_med_fi lter ( s e l f , message , r e c i v e r ) :

362 """

363 method used to apply MED f i l t e r s to r e c i v ed BGP L{Update} messages

364 @param message : BGP Update message

365 @param r e c i v e r : the Router ob j e c t o f the route r r e c i v i n g / apply ing f i l t e r

366 """

367 i f r e c i v e r . ignore_all_med or ( message . next_hop_as in r e c i v e r . ignore_as_med ) or \

368 (message . next_hop in r e c i v e r . ignore_router_med ) :

369 message .med = None

370 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 fully our BGP

implementation.

Listed: 100% of module code

7 # Indexes o f a t t r i b u t e s with in a route tup l e

8 ORIGIN_LOC = 0

9 AS_PATH_LOC = 1

29

10 NEXT_HOP_LOC = 2

11 NEXT_HOP_AS_LOC = 3

12 MED_LOC = 4

13 LOCAL_PREF_LOC = 5

14 HEARD_FROM_LOC = 6

15 HEARD_FROM_IBGP_LOC = 7

16 CONFEDERATION_LOC = 8

17 IGP_DIST_LOC = 9

18

19 class Update :

20 """

21 Update ob j e c t r ep r e s en t i ng a BGP update message s t r u c tu r e

22 """

23 def __init__( s e l f , p r e f i x , o r i g i n , as_path , next_hop , next_hop_as ,med , l oca l_pre f ,

24 igp_dist , c on f ede ra t i on ) :

25 """

26 method used to i n i t i a l i s e a BGP update messages , to i n i t i a l i s e a BGP message a p r e f i x must

27 be passed to i t a long with a l l i t s a t t r i b u t e s that are r equ i e rd f o r an UPDATE message

28 """

29 s e l f . o r i g i n = o r i g i n

30 s e l f . as_path = as_path

31 s e l f . next_hop = next_hop

32 s e l f . next_hop_as = next_hop_as

33 s e l f .med = med

34 s e l f . l o c a l_pr e f = lo ca l_pr e f

35 s e l f . n l r i = [ ]

36 s e l f . withdrawn = [ ]

37 s e l f . i gp_dist = igp_dist

38 s e l f . c on f ede ra t i on = con f ede ra t i on

39 i f p r e f i x != ' ' : s e l f . n l r i . append ( p r e f i x )

40

41 def accept_pre f ix ( s e l f , p r e f i x , o r i g i n , as_path , next_hop , next_hop_as ,med , l oca l_pre f ,

42 igp_dist , c on f ede ra t i on ) :

43 """

44 method used to accept a p r e f i x / route in to t h i s messages n l r i , i . e . i f the p r e f i x has the

45 same route / a t t r i b u t e s as the p r e f i x that i n i t i a l i s e d t h i s message then we add i t to the

46 n l r i

47 """

48 i f s e l f . o r i g i n == o r i g i n \

49 and s e l f . as_path == as_path \

50 and s e l f . next_hop == next_hop \

51 and s e l f . next_hop_as == next_hop_as \

52 and s e l f .med == med \

53 and s e l f . l o c a l_pr e f == loca l_pre f \

54 and s e l f . i gp_dist == igp_dist \

55 and s e l f . c on f ede ra t i on == con f ede ra t i on :

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

57 return True

58 return False

59

60 class BGP_Table :

61 """

62 Represents the RIB on a route r running BGP

63 @ivar ent rys : L{map} o f p r e f i x e s to the re L{BGP_Table_Entry} ' s

64 @ivar changes : L{ l i s t } o f p r e f i x e s that have changes with in them

65 """

66 def __init__( s e l f ) :

67 s e l f . ent rys = {}

68 s e l f . changes = [ ]

30

69

70 def i tems ( s e l f ) :

71 """

72 r e tu rn s items f o r ent rys he ld with in the RIB

73 """

74 return s e l f . en t rys . i tems ( )

75

76 def add ( s e l f , entry ) :

77 """

78 Adds an entry to the RIB

79 @param entry : L{BGP_Table_Entry} ob j e c t r ep r e s en t i ng an entry f o r a p r e f i x

80 """

81 s e l f . ent rys [ entry . p r e f i x ] = entry

82

83 def get ( s e l f , p r e f i x ) :

84 """

85 Returns the entry f o r a g iven p r e f i x

86 @param p r e f i x : p r e f i x to r e t r i v e entry f o r

87 @return : L{BGP_Table_Entry entry } f o r a s p e c i f i e d p r e f i x

88 """

89 return s e l f . en t rys [ p r e f i x ]

90

91 def has_entry ( s e l f , p r e f i x ) :

92 """

93 r e tu rn s the s t a tu s o f an ent rys ex i s t an c e f o r a g iven p r e f i x

94 @param p r e f i x : p r e f i x to check ent rys ex i s t an c e f o r

95 @return : True i f p r e f i x entry e x i s t s , Fa l se o therw i se

96 """

97 i f p r e f i x in s e l f . en t rys : return True

98 return False

99

100 def check_change ( s e l f , p r e f i x ) :

101 """

102 method that checks i f the p r e f i x entry f o r a p r e f i x has any changed route s with in i t

103 @param p r e f i x : the p r e f i x to check change s t a t e f o r

104 """

105 i f l en ( s e l f . en t rys [ p r e f i x ] . changes ) != 0 and p r e f i x not in s e l f . changes :

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

107

108 def delete_change ( s e l f ) :

109 """

110 method that c l e a r s a l l changes from th i s t ab l e

111 """

112 for p r e f i x in s e l f . changes :

113 # i f t h i s change f l a g was not f o r the complete removal o f a p r e f i x then

114 # i t s t i l l e x i s t s and we must c l e a r i t s l i s t o f changed route s

115 i f p r e f i x in s e l f . en t rys :

116 del s e l f . en t rys [ p r e f i x ] . changes [ : ]

117 del s e l f . changes [ : ]

118 class BGP_Table_Entry :

119 """

120 Represents a s t r u c tu r e f o r an entry f o r a p r e f i x in the BGP RIB L{BGP_Table}

121 @ivar p r e f i x : the p r e f i x t h i s BGP tab l e entry i s f o r

122 @ivar route s : L{map} o f route i d s to route s heard f o r t h i s p r e f i x

123 @ivar heard_from_to_id : L{map} o f the ip addre s s e s a route i s heard from to the id o f the

124 route heard

125 @ivar route_count : the number o f route s cu r r en t l y in the tab l e entry

126 @ivar best_route_number : the route id o f the best route f o r t h i s p r e f i x

127 @ivar changes : a l i s t o f a l l the route i d s that have changed

31

128 (new winner , or imp l i c t r ep l a c e , or withdrawn )

129 """

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

131

132 s e l f . p r e f i x = p r e f i x

133 s e l f . r ou t e s = {}

134 s e l f . heard_from_to_id = {}

135 s e l f . route_count = 0

136 s e l f . best_route_number = None

137 s e l f . changes = [ ]

138

139 def add_route ( s e l f , o r i g i n , as_path , next_hop , next_hop_as ,med , l oca l_pre f , heard_from ,\

140 heard_from_ibgp , con f ede ra t i on , igp_dist ) :

141 """

142 Adds a heard route f o r t h i s p r e f i x to t h i s entry

143 @return : route id o f the added route

144 """

145 route_id = s e l f . route_count

146 i f heard_from in s e l f . heard_from_to_id :

147 route_id = s e l f . heard_from_to_id [ heard_from ]

148 i f s e l f . best_route_number == route_id :

149 #Imp l i c i t l y r ep l aced , but only send i t on i f i t s our bes t route

150 s e l f . changes . append ( route_id )

151 else :

152 # Just s imply a new route

153 s e l f . heard_from_to_id [ heard_from ] = route_id

154 s e l f . route_count +=1

155

156 s e l f . r out e s [ route_id ] = ( o r i g i n , as_path , next_hop , next_hop_as ,med ,

157 loca l_pre f , heard_from , heard_from_ibgp , con f ede ra t i on , igp_dist )

158

159 return route_id

160 def get_route ( s e l f , route_id ) :

161 """

162 r e tu rn s the route tup l e f o r a s p e c i f i e d route

163 @param route_id : the id o f the route we have to re turn

164 @return : the L{ tup l e } ho ld ing route in fo rmat ion

165 """

166 return s e l f . r ou t e s [ route_id ]

167

168 def get_best_route ( s e l f ) :

169 """

170 r e tu rn s the route tup l e f o r the best route f o r t h i s entry

171 @return : the L{ tup l e } ho ld ing route in fo rmat ion

172 """

173 return s e l f . get_route ( 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 def accept_ses s ion ( s e l f , s e s s i o n ) :

71 """

72 Used to accept connect ion attempts from other daemons , accept s the s e s s i o n

73 i f the daemon i s p r e con f i gu r ed to accept , or i f the daemon i s wa i t ing f o r a

74 random peer

75 @param : Se s s i on the daemon s e s s i o n proposed by the other daemon

76 """

77 # s i n c e the s e s s i o n i s proposed to us then we are at end 1 o f the s e s s i o n

78 i f s e s s i o n . enda [ 0 ] in s e l f . con f igured_peers :

79 s e l f . pee r_se s s i ons [ s e s s i o n . enda [ 0 ] . ip ] = s e s s i o n

80 s e l f . con f igured_peers . remove ( s e s s i o n . enda [ 0 ] )

81 return True

82 e l i f s e l f . awaiting_random_peer :

83 s e l f . pee r_se s s i ons [ s e s s i o n . enda [ 0 ] . ip ] = s e s s i o n

84 s e l f . awaiting_random_peer = False

85 return True

86 return False

Method that veri�es received messages

114 def new_sessions_handler ( s e l f ) :

115 """

116 method used to t ry and br ing a pee r ing s e s s i o n s with con f i gu r ed pee r s

117 these pee r s could have been con f i gu r ed manually or by accept ing an RPR.

118 communications here happen over IP

119 i . e . s imulated through d i r e c t communication through daemon ob j e c t s

120 """

121 for peer in s e l f . con f igured_peers :

122 s e s s i o n = P2P_Session ( s e l f , peer )

123 i f peer . accept_ses s ion ( s e s s i o n ) :

124 s e l f . pee r_se s s i ons [ peer . ip ] = s e s s i o n

125 #pr in t 'SESSION ' , peer . ip , ' == ' , s e l f . ip

126 s e l f . con f igured_peers . remove ( peer )

160 def i s_va l i d ( s e l f , message ) :

161 """

162 Used to check that a r e c e i v ed message i s v a l i d , a pp l i e s s e v e r a l checks which are as f o l l ow s

163 1 . i f the source o f the message i s the as t h i s daemon r ep r e s en t s then i n v a l i d

164 2 . i f the message i s o f PKE type then ensure that the message v e r i f i e s with the pub l i c

165 key with in i t or with the pub l i c key ( i f any ) he ld f o r the AS number with in i t

166 ( because i t may be a key change )

167 3 . The messages s i gna tu r e can be v e r i f i e d us ing the key we have f o r the AS that sent i t

168 i f no key held or cannot v e r i f y then message i s i n v a l i d

169 4 . The message time−stamp i s +− the time−stamp window otherw i se i n v a l i d

170 @param : L{Message} to va l i d a t e

171 @return : True i f the message i s va l i d , Fa l se o therw i se

172 """

173 source , type = message . ge tS ta t e ( "SOURCE_AS" ) , message . g e tS ta t e ( "TYPE" )

174

175

176 i f source == s e l f . advert i sed_as :

177 i f type == PKE_TYPE and message . ge tS ta t e ( "PUBLIC_KEY")!= s e l f . c rypte r . public_key :

178 #pr in t ' Hi jack '

179 s e l f . add_to_log (KEY_HIJACK, ' Publ ic Key ' , message . ge tS ta t e ( "CONTACT_IP" ) , ' ' )

180 return False

181 e l i f type == PKE_TYPE :

182 # Must v e r i f y with e i t h e r i n t e r n a l pub l i c key , or he ld p r i va t e key ( key change )

183 i f not ( s e l f . c rypte r . v e r i f y (message , message . g e tS ta t e ( "PUBLIC_KEY" ) ) \

33

184 or s e l f . c rypte r . v e r i f y ( message ) ) :

185 return False

186 # Timestamp window does not apply to PKE messages , whole po int i s that they

187 # should be rep layed un t i l changed , when changed then old PKE' s w i l l not v e i r f y

188 return True

189 #I f we cant v e r i f y the message us ing the c rypte r component then message i s i n v a l i d

190 i f not s e l f . c rypte r . v e r i f y ( message ) :

191 print ' I nva l i d Message ' , message . ge tS ta t e ( "TYPE" )

192 return False

193 # as s ta t ed message time stamp must = +− TIME_STAMP_WINDOW

194 # OBSELETE, REPLAY ATTACKS ARE NO DELT WITH USING SEQNO , SEE the process_message method

195 time_window = Globals .TIME − message . ge tS ta t e ( "TIMESTAMP" )

196 i f abs ( time_window) > TIME_STAMP_WINDOW:

197 return False

198 return True

Methods that process some of the received messages

199

200

201 def process_cra ( s e l f , source_sess ion , message ) :

202 """

203 Bounces r e c e i v ed CRA messages onto the graph proc e s s o r on t h i s daemon , i f the CRA message

204 had paths accepted / l i f e extended in the graph then f l o od the message on to a l l pee r s ,

205 and in sp e c t the message to see i f i t uncovers a t tack s

206 @param source_ses s i on : the s e s s i o n t h i s message was heard from

207 @param message : the ac tua l L{Message} heard

208 """

209 i f s e l f . graph . commit (message , source_ses s i on ) :

210 s e l f . f lood_message (message , source_ses s i on )

211 s e l f . a l e r t_hand le r ( message )

212

213

214 def process_pke ( s e l f , source_sess ion , message ) :

215 """

216 Used to handle va l i da t ed PKE messages , handl ing the PKE e n t a i l s an attempt to a s s e r t

217 the pub l i c key with in i t i n to our s t o r e f o r the AS adve r t i s ed in the PKE .

218 i f t h i s key i s new or causes a c o n f l i c t then f l o od the message

219 @param source_ses s i on : the s e s s i o n t h i s message was heard from

220 @param message : the ac tua l L{Message} heard

221 """

222 s i g n a l = s e l f . c rypte r . commit ( message )

223 i f s i g n a l == KEY_COMMITED_SIGNAL or s i g n a l == KEY_CONFLICT_SIGNAL:

224 i f s i g n a l == KEY_CONFLICT_SIGNAL :

225 True

226 s e l f . f lood_message (message , source_sess ion , True )

227

228 def process_rpr ( s e l f , source_sess ion , message ) :

229 """

230 When we r e c e i v e a RPR message then we accept i t i f we have space f o r pee r ing and the

231 message has l e s s than 5 hops l e f t , o the rw i s e bounce the message on to a random peer s e s s i o n

232 i f i t has 0 > hops < 100 l e f t .

233 @param source_ses s i on : the s e s s i o n t h i s message was heard from

234 @param message : the ac tua l L{Message} heard

235 """

236 hops = message . ge tS ta t e ( "HOPS" )

237 c_ip = message . ge tS ta t e ( "CONTACT_IP" )

238 i f hops < 5 and l en ( s e l f . pee r_se s s i ons ) < s e l f . maximum_peerings and not\

239 c_ip in s e l f . pee r_se s s i ons :

34

240 # communication w i l l now happen over IP d i r e c t l y , so we s imua l te that

241 # by pu l l i n g up the daemon ob j e c t f o r the ip in the RPR message and s t o r i n g that in

242 # con f i gu r ed pee r s f o r l a t e r connect ion

243 source_daemon = Globals .ROUTERS[ c_ip ] . daemon

244 s e l f . con f igured_peers . append ( source_daemon )

245 return

246 e l i f hops != 0 and hops < 64 :

247 message . s e t S t a t e ( "HOPS" , hops − 1)

248 s e s s i o n = cho i c e ( s e l f . pee r_se s s i ons . va lue s ( ) )

249 s e s s i o n . transmit_message ( s e l f . ip , message )

Method that scans valid CRA messages for attacks

250 def a le r t_hand le r ( s e l f , message ) :

251 """

252 Proce s s e s a r e c i v ed CRA message that caused a s t a t e change in the

253 daemon Graph , i t checks a l l ( p r e f i x , path ) pa i r s f o r h i j a ck attempts and th r e a t s

254 on i t s r ep r e s ented AS i . e . the AS i t s rout e r be longs to

255 @param message : L{Message} r e c e i v ed by t h i s daemon

256 """

257 payload = message . ge tS ta t e ( "PAYLOAD" )

258 # Id en t i f y from the BGP tab l e o f the route r t h i s daemon i s running on a l l the p r e f i x e s

259 # owned by the AS i t i s running on i . e . AS−PATH = ' '

260 # map f o r f a s t lookup

261 l o c a l = {}

262 for entry in s e l f . bgp_table . ent rys . va lue s ( ) :

263 for route in entry . route s . va lue s ( ) :

264 i f route [AS_PATH_LOC] == "" :

265 l o c a l [ entry . p r e f i x ] = 0

266 break

267

268 for p r e f i x in payload :

269 i f p r e f i x in l o c a l :

270 # I f t h i s i s a p r e f i x e x p l i c i t l y owned by the daemons r epre s en ted AS the

271 # look f o r p r e f i x h i j a c k s

272

273 # Check every path f o r p r e f i x h i j a c k s

274 for path in payload [ p r e f i x ] :

275 l ength = len ( path )

276 i f path [ length −1] != s t r ( s e l f . advert i sed_as ) :

277 # DIRECT PREFIX HIJACK i . e . path shows d i f f r e n t source

278 cause = path [ length −1]

279 s e l f . add_to_log (DIRECT_PREFIX_HIJACK, pr e f i x , ' System '+cause , path )

280

281 i f ( p r e f i x , cause ) in S t a t i s t i c s .ATTACKS:

282 S t a t i s t i c s .ATTACKS[ ( p r e f i x , cause ) ] = True

283 e l i f l ength > 1 and path [ length −2] not in s e l f . as_peers :

284 # INDIRECT PREFIX HIJACK i . e . path shows fake connect ion to to the r e a l source

285 cause = path [ length −2]

286 s e l f . add_to_log (INDIRECT_PREFIX_HIJACK, pr e f i x , ' System '+cause , path )

287 i f ( p r e f i x , cause ) in S t a t i s t i c s .ATTACKS:

288 S t a t i s t i c s .ATTACKS[ ( p r e f i x , cause ) ] = True

289 else :

290 i f p r e f i x in s e l f . graph . pre f ix_paths :

291 # Pre f i x may not be in the map i f t r i p l e s not in map used a lone

292 lowest , h i ghe s t = s e l f . graph . get_pre f ix_trust_metr ics ( p r e f i x )

293 i f h ighe s t [ 0 ] > MINIMUM_TRUST and l owest [ 1 ] in payload [ p r e f i x ] and \

294 lowest [ 0 ] < 0 .5∗ h ighe s t [ 0 ] :295 # UNTRUSTED ROUTE i . e . t h i s i s not the only path f o r the p r e f i x

35

296 # and i t has the worst t r i p l e s c o r e

297 S t a t i s t i c s .THIRD_PARTY_ATTACKS[ p r e f i x ] = True

298 s e l f . add_to_log (UNTRUSTED_PATH_SEEN, p r e f i x , s t r ( l owest [ 1 ] )+ " Tr ip l e "+\

299 s t r ( lowest [ 2 ] ) , l owest [ 1 ] )

300 # I f t h i s p r e f i x i s not e x p l i c i t l y owned by the daemons r epre s en ted AS then

301 # look f o r DEAGGREGATION attacks

302 check_format = p r e f i x . r s p l i t ( "/" )

303 for l o c a l_p r e f i x in l o c a l :

304 i f 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 ) :

305 # i f t h i s p r e f i x i s a deaggregat ion o f any p r e f i x owned by the daemons AS

306 # and the daemon was not to ld i t could be deaggregated then warn

307 i f l o c a l_p r e f i x in s e l f . deaggregate_pre f i xe s :

308 break

309 path = payload [ p r e f i x ] [ 0 ]

310 cause = path [ l en ( path )−1]

311 i f ( l o ca l_pre f i x , cause ) in S t a t i s t i c s .ATTACKS:

312 S t a t i s t i c s .ATTACKS[ ( l o ca l_pre f i x , cause ) ] = True

313 s e l f . add_to_log (DEAGGREGATION_HIJACK, l o ca l_pre f i x , p r e f i x , path )

314 break

315 # Check every path f o r po l i c y v i o l a t i o n s

316 for path in payload [ p r e f i x ] :

317 i f s t r ( s e l f . advert i sed_as ) in path :

318 index = l i s t ( path ) . index ( s t r ( s e l f . advert i sed_as ) )

319 i f index < len ( path)−1 and index > 0 :

320 t = path [ index −1]

321 f = path [ index+1]

322 i f f in s e l f . as_peers and t in s e l f . as_peers :

323 i f s e l f . as_peers [ t ] in Globals . POLICIES [ s e l f . as_peers [ f ] ] :

324 s e l f . add_to_log (POLICY_VIOLATION, p r e f i x , ' System '+t , path )

Method that generates the CRA messages, called periodically

342 def graph_handler ( s e l f ) :

343 """

344 P e r i o d i c a l l y r e a s s e r t s a l l cu r r ent route s in to the graph , i t then f l o o d s

345 a l l r oute s i t s e e s that pass i t s suppre s s i on modes , uses the methods used by commit that check a

346 route s v a l i d i t y aga in s t suppre s s i on modes then i n s e r t i t i n to the graph ( namely the accept ( ) method )

347 i f the r e are paths to send the generate a CRA message and f l o od i t .

348 c l e an s the graph to keep i t l i v e

349 c l e an s the l og to keep i t l i v e

350 """

351 payload , s i z e = {} ,0

352 for ( p r e f i x , entry ) in s e l f . bgp_table . i tems ( ) :

353 for route in entry . route s . va lue s ( ) :

354 as_path = tup l e ( ( s t r ( s e l f . advert i sed_as)+" "+route [AS_PATH_LOC] ) . s t r i p ( ) . s p l i t ( ) )

355 i f s e l f . graph . accept ( p r e f i x , as_path ,2∗ASSERTION_RATE) :356 i f p r e f i x not in payload : payload [ p r e f i x ] = [ as_path ]

357 else : payload [ p r e f i x ] . append ( as_path )

358 s i z e += 1

359 i f s i z e > 0 :

360 message = CRA( s e l f . advert ised_as , payload ,2∗ASSERTION_RATE, Globals .TIME, s e l f .SEQ)

361 message = s e l f . c rypte r . s i gn ( message )

362 s e l f .SEQ += 1

363 s e l f . f lood_message (message , None )

364 s e l f . graph . c lean_expired ( )

365 s e l f . c lean_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: 30% of module code

80 def suppres s ( s e l f , as_path , p r e f i x ) :

81 """

82 Applys the ac t i va t ed suppre s s i on modes in t h i s s imu la t i on to a path seen f o r a p r e f i x

83 @param p r e f i x : the p r e f i x

84 @param as_path : the AS−PATH seen f o r the p r e f i x

85 @return : True i f t h i s path should not be added to the graph , Fa l se o the rw i s e

86 """

87 SUPPRESSION = Globals .SUPPRESSION

88 i f l en (SUPPRESSION) == 0 : return False

89 i f not ( (CLOSEST in SUPPRESSION and s e l f . i s_ c l o s e s t ( as_path , p r e f i x ) ) or \

90 (TRIPLES_NOT_IN_MAP in SUPPRESSION and s e l f . has_triples_not_in_map ( as_path , p r e f i x ) ) or \

91 (NOT_SUBSET_OF_CLOSEST in SUPPRESSION and s e l f . i s_not_subset_of_closest ( as_path , p r e f i x ) ) ) :

92 return True

93 return False

94

95 def r e a s s e r t ( s e l f , as_path , p r e f i x ) :

96 """

97 Applys the ac t i va t ed suppre s s i on modes in t h i s s imu la t i on to a path seen f o r a p r e f i x ,

98 however t h i s path i s a r e a s s e r t i o n and we must check that i t s t i l l pa s s e s the suppre s s i on

99 modes

100 @param p r e f i x : the p r e f i x

101 @param as_path : the AS−PATH seen f o r the p r e f i x

102 @return : True i f t h i s path should not be added to the graph , Fa l se o the rw i s e

103 """

104 SUPPRESSION = Globals .SUPPRESSION

105 length = len ( as_path )

106 i f l en (SUPPRESSION) == 0 : return True

107 # a map o f the l i s t o f equa l l y c l o s paths in our map f o r t h i s p r e f i x ,

108 # keyed by the paths source

109 c lo se s t_paths = s e l f . get_closest_paths ( p r e f i x )

110 s r c = as_path [ length −1]

111 i f CLOSEST in SUPPRESSION:

112 # I f CLOSEST suppre s s i on mode i s on then the path must be one o f the equa l l y c l o s e

113 # paths seen f o r t h i s p r e f i x with the p a r t i c u l a r source in the as_path

114 i f as_path in c lo se s t_paths [ s r c ] [ 0 ] : return True

115 i f TRIPLES_NOT_IN_MAP in SUPPRESSION :

116 # I f TRIPLES_NOT_IN_MAP suppre s s i on mode i s on then t h i s path must have a t l e a s t one

117 # t r i p l e such that i f the path i s de l e t ed the t r i p l e w i l l e xp i r e

118 #i . e Refrence count −1 = 0

119 i f l ength <= 2 :

120 i f s e l f . t r i p l e s [ as_path ] [ 0 ] − 1 == 0 : return True

121 else :

122 a , b , c = length −3, length −2, length−1123 while a != −1 :

124 i f s e l f . t r i p l e s [ ( as_path [ a ] , as_path [ b ] , as_path [ c ] ) ] [ 0 ] − 1 == 0 :

125 return True

126 a , b , c = a−1,b−1,c−1127 i f NOT_SUBSET_OF_CLOSEST in SUPPRESSION :

128 # I f NOT_SUBSET_OF_CLOSEST suppre s s i on mode i s on , then there should be no

37

129 # path such that t h i s path i s a subset o f i t except t h i s path i t s e l f

130 # becuase i t s obv ious ly s t i l l in the map

131 s i z e = c lo se s t_paths [ s r c ] [ 1 ]

132 paths = c lo se s t_paths [ s r c ] [ 0 ]

133 for c l o s e s t in paths :

134 i f c l o s e s t == as_path : continue

135 # I f t h i s path i s a subset o f any path expet i t s e l f then f a i l

136 index = 1

137 while not ( index > s i z e or index > length ) :

138 i f c l o s e s t [ s i z e − index ] == as_path [ l ength − index ] and index != 1 :

139 return False

140 index += 1

141 return True

142

143 return False

144

145 def get_closest_paths ( s e l f , p r e f i x ) :

146 """

147 Gets the paths s to r ed in the graph that are equa l l y c l o s e in terms o f hop counts f o r a

148 p r e f i x

149 @return : L{map} in format C{( p r e f i x source , ( paths length , l i s t ( paths ) ) ) }

150 """

151 c l o s e s t = {}

152 # f o r every path that the t ab l e ho lds f o r the p r e f i x

153 for path in s e l f . pre f ix_paths [ p r e f i x ] . paths . keys ( ) :

154 # source i s i t s f i r s t hop , ( in l a s t index ) . BGP prepends

155 l ength = len ( path )

156 s r c = path [ length −1]

157 i f s r c not in c l o s e s t :

158 c l o s e s t [ s r c ] = [ [ path ] , l ength ]

159 e l i f l ength < c l o s e s t [ s r c ] [ 1 ] :

160 # i f t h i s path i s c l o s e r then the other paths then r e s e t the l i s t o f paths

161 c l o s e s t [ s r c ] [ 1 ] = length

162 c l o s e s t [ s r c ] [ 0 ] = [ path ]

163 e l i f l ength == c l o s e s t [ s r c ] [ 1 ] :

164 # i f i t i s equa l l y c l o s e then add i t to the l i s t o f paths

165 c l o s e s t [ s r c ] [ 0 ] . append ( path )

166 return c l o s e s t

167

168 def i s_ c l o s e s t ( s e l f , as_path , p r e f i x ) :

169 """

170 Returns t rue i f t h i s as_path i s the c l o s e s t path seen f o r the p r e f i x

171 f o r the p a r t i c u l a r source o f the path i . e . no other path f o r t h i s p r e f i x from th i s source

172 in the map i s as c l o s e as i t

173 @param as_path : the path to check

174 @param p r e f i x : the p r e f i x the path i s f o r

175 @return : True i f as_path i s the c l o s e s t by prev ious d e f i n i t i o n , Fa l se o therw i s e

176 """

177 # i f we dont even have the p r e f i x then obv ious ly i t s the c l o s e s

178 i f p r e f i x not in s e l f . pre f ix_paths : return True

179 c lo se s t_paths = s e l f . get_closest_paths ( p r e f i x )

180 l ength = len ( as_path )

181 s r c = as_path [ length −1]

182 i f s r c not in c lo se s t_paths : return True

183 i f c lo se s t_paths [ s r c ] [ 1 ] >= length : return True

184 return False

185

186 def has_triples_not_in_map ( s e l f , as_path , p r e f i x ) :

187 """

38

188 Returns t rue i f t h i s as_path has a t r i p l e not p r ev i ou s l y known to t h i s graph

189 @param as_path : the path to check

190 @param p r e f i x : the p r e f i x the path i s f o r

191 @return : True i f as_path has a t l e a s t on t r i p l e no in the map , Fa l se o therw i se

192 """

193 l ength = len ( as_path )

194 i f l ength <= 2 :

195 i f as_path not in s e l f . t r i p l e s : return True

196 else :

197 a , b , c = length −3, length −2, length−1198 while a != −1 :

199 i f ( as_path [ a ] , as_path [ b ] , as_path [ c ] ) not in s e l f . t r i p l e s :

200 return True

201 a , b , c = a−1,b−1,c−1202 return False

203

204 def i s_not_subset_of_closest ( s e l f , as_path , p r e f i x ) :

205 """

206 Returns t rue i f t h i s as_path i s not a subset o f any p r e f i x seen f o r t h i s path with

207 t h i s paths p a r t i c u l a r source

208 @param as_path : the path to check

209 @param p r e f i x : the p r e f i x the path i s f o r

210 @return : True i f as_path i s not a subset o f any p r e f i x seen f o r the path , Fa l se o therw i se

211 """

212 i f p r e f i x not in s e l f . pre f ix_paths : return True

213 c lo se s t_paths = s e l f . get_closest_paths ( p r e f i x )

214 l ength = len ( as_path )

215 s r c = as_path [ length −1]

216 i f s r c not in c lo se s t_paths : return True

217 s i z e = c lo se s t_paths [ s r c ] [ 1 ]

218 paths = c lo se s t_paths [ s r c ] [ 0 ]

219 for c l o s e s t in paths :

220 index = 1

221 while not ( index > s i z e or index > length ) :

222 i f c l o s e s t [ s i z e − index ] == as_path [ l ength − index ] and index != 1 :

223 return False

224 index += 1

225 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: 85% of module code

7 class PVP:

8 """

9 This c l a s s i s a d e s c r i p t i o n o f an in s t ance o f our over l ay p ro to co l running on

10 som EWSD machine

11 @ivar routing_base : the rout ing tab l e o f the in s t ance

12 @ivar s e s s i on_ in f o : maps i t s EWSDs s e s s i o n s to exponent i a l d i s t . met r i c s

13 @ivar changes : ho lds the l i s t o f d e s t i n a t i o n s whose e n t i e s have changed

14 @ivar last_change : ho lds the l a s t time at which an announcment was r e c e i v ed

15 @ivar daemon : a r e f r e n c e to the L{Daemon} ob j e c t owning t h i s p ro to co l

16 """

17 def __init__( s e l f , daemon ) :

39

18 s e l f . routing_base = {daemon . advert i sed_as : Table_Entry ( ' ' , 0 ,LOCAL)}

19 s e l f . s e s s i on_ in f o = {}

20 s e l f . used_sess ions = [ ]

21 s e l f . metr ic_vector = 0

22 s e l f . changes = {}

23 s e l f . last_change = Globals .TIME

24 s e l f . daemon = daemon

25

26 def sess ion_up ( s e l f , s e s s i o n ) :

27 """

28 Cal led by the owner EWSD to i nd i c a t e that a new s e s s i o n has come on l i n e

29 @param s e s s i o n : the L{P2P_Session} that has j u s t been bought on l i n e

30 """

31 s e l f . s e s s i on_ in f o [ s e s s i o n ] = 20∗∗ s e l f . metr ic_vector

32 s e l f . metr ic_vector += 1

33 # Send the f u l l RIB over that s e s s i o n

34 s e l f . g ene r e ra t e ( s e s s i on , s e l f . s e s s i on_ in f o [ s e s s i o n ] , True )

35

36 def session_down ( s e l f , s e s s i o n ) :

37 """

38 Cal led by the owner EWSD to i nd i c a t e that a s e s s i o n has come o f f l i n e

39 @param s e s s i o n : the L{P2P_Session} that has j u s t been bought o f f l i n e

40 """

41 del s e l f . s e s s i on_ in f o [ s e s s i o n ]

42 for de s t i n a t i on in s e l f . routing_base . keys ( ) :

43 s e l f . handle_session_withdraw ( de s t i na t i on , s e s s i o n )

44

45 def handle_session_withdraw ( s e l f , d e s t i na t i on , s e s s i o n ) :

46 """

47 Handles a s e s s i o n withdrawal event , c a l l e d f o r every d e s t i n a t i on with in

48 a RIB when a s e s s i o n i s bought o f f l i n e , l i k ew i s e c a l l e d f o r

49 a p a r t i c u l a r d e s t i n a t i on when i t i s withdrawn from a pa r t i c u l a r s e s s i o n

50 @param de s t i n a t i on : ho lds the d e s t i n a t i on that was withdrawn

51 @param s e s s i o n : ho lds the s e s s i o n that withdew i t

52 """

53 entry = s e l f . routing_base [ d e s t i n a t i on ]

54 for route_id in entry . route s . keys ( ) :

55 # remove any route heard from the s e s s i o n f o r the d e s t i n a t i on

56 i f entry . route s [ route_id ] [ 2 ] == s e s s i o n :

57 del entry . route s [ route_id ]

58 # I f the best route was withdrawn , then e i t h e r imp l i c i t / e x p l i c i t r ep l a c e

59 i f entry . best_route not in entry . route s :

60 i f l en ( entry . r oute s ) == 0 : # EXPLICIT , w i l l be sent next s imstep

61 del s e l f . routing_base [ d e s t i n a t i on ]

62 else : # imp l i c i t , w i l l be sent next s imstep

63 winner , metr ic = None , f l o a t ( ' i n f ' )

64 for id , route in entry . route s . i tems ( ) :

65 i f route [ 1 ] < metr ic :

66 metr ic , winner = route [ 1 ] , id

67 entry . best_route = winner

68 # f l a g t h i s d e s t i n a t i on as changed

69 s e l f . changes [ d e s t i n a t i on ] = 1

70 s e l f . last_change = Globals .TIME

71

72

73 def r e c e i v e ( s e l f , s e s s i on , packet ) :

74 """

75 Process an RPO message r e c e i v ed by the EWSD owner

76 @param s e s s i o n : the s e s s i o n the RPO was r e c e i v ed on

40

77 @param packet : the message/ packet

78

79 """

80 payload = packet . g e tS ta t e ( "PAYLOAD" )

81 r i b = s e l f . routing_base

82

83 for de s t i n a t i on in payload [ 1 ] : # WITHDAWALS

84 i f de s t i n a t i on in s e l f . routing_base :

85 s e l f . handle_session_withdraw ( de s t i na t i on , s e s s i o n )

86

87 for de s t i na t i on , path , metr ic in payload [ 0 ] : # UPDATES

88 i f s t r ( s e l f . daemon . advert i sed_as ) in path . s p l i t ( ) :

89 continue

90 metr ic += s e l f . s e s s i on_ in f o [ s e s s i o n ]

91 i f de s t i n a t i on not in r i b :

92 s e l f . routing_base [ d e s t i n a t i on ] = Table_Entry ( path , metric , s e s s i o n )

93 s e l f . changes [ d e s t i n a t i on ] = 1

94 else :

95 entry = s e l f . routing_base [ d e s t i n a t i on ]

96 best = entry . r oute s [ entry . best_route ]

97 i f s e s s i o n in entry . heard_from_to_id :

98 entry . route s [ entry . heard_from_to_id [ s e s s i o n ] ] = ( path , metric , s e s s i o n )

99 id = entry . heard_from_to_id [ s e s s i o n ]

100 else :

101 id = entry . add_route ( path , metric , s e s s i o n )

102 i f best [ 1 ] > metr ic :

103 entry . best_route = id

104 s e l f . changes [ d e s t i n a t i on ] = 1

105 s e l f . last_change = Globals .TIME

106

107 def gene r e ra t e ( s e l f , s e s s i on , metric , f u l l_ r i b = False ) :

108 """

109 Create and t ransmit s a rout ing packet cons t ruc ted f o r a p a r t i c u l a r s e s s i o n

110 @param s e s s i o n : the L{P2P_Session} t h i s rout ing packet i s f o r

111 @param metr ic : the metr ic o f t h i s s e s s i o n

112 @param fu l l_ r i b : i n d i c a t e s whether the whole rout ing tab l e must be sent or

113 j u s t changes

114 """

115 i f f u l l_ r i b : keys = s e l f . routing_base

116 else : keys = s e l f . changes

117 payload = ( [ ] , [ ] )

118 r i b = s e l f . routing_base

119 for de s t i n a t i on in keys :

120 i f de s t i n a t i on not in s e l f . routing_base :

121 # means i t has been withdrawn with no a l t e r n a t i v e route s hence de l e t ed

122 payload [ 1 ] . append ( d e s t i n a t i on )

123

124 entry = r i b [ d e s t i n a t i on ]

125 route = entry . route s [ entry . best_route ]

126 path = route [ 0 ] + ' ' + s t r ( s e l f . daemon . advert i sed_as )

127 payload [ 0 ] . append ( ( de s t i na t i on , path , route [ 1 ] ) )

128

129 message = PVPM( s e l f . daemon . advert ised_as , payload , Globals .TIME, s e l f . daemon .SEQ)

130 message = s e l f . daemon . c rypte r . s i gn ( message )

131 s e l f . daemon .SEQ += 1

132 s e s s i o n . transmit_message ( s e l f . daemon . ip , message )

133

134 def ca l cu late_used ( s e l f ) :

135 """

41

136 Cal led upon convergence / reconvergence o f t h i s p ro to co l i n s tace , i d e n t i f i e s and

137 s t o r e s which s e s s i o n s are not redundant , i . e . appear in the rout ing tab l e

138 """

139 s e s s i o n s = {}

140 for de s t i na t i on , entry in s e l f . routing_base . i tems ( ) :

141 s e s s i o n = entry . route s [ entry . best_route ] [ 2 ]

142 i f s e s s i o n == LOCAL : continue

143 s e s s i o n s [ s e s s i o n ] = True

144

145 s e l f . used_sess ions = s e s s i o n s . keys ( )

146 #i f l en ( s e l f . used_sess ions ) < len ( s e l f . s e s s i on_ in f o ) :

147 # pr in t ' Saved ' , l en ( s e l f . s e s s i on_ in f o ) − l en ( s e l f . used_sess ions )

148

149 def s imulate ( s e l f ) :

150 """

151 Cal led by the owner EWSD (L{Daemon}) to s imulate i t s p ro to co l i n s t ance

152

153 """

154 i f l en ( s e l f . changes ) != 0 :

155 # send changes over a l l s e s s i o n s

156 for s e s s i on , metr ic in s e l f . s e s s i on_ in f o . i tems ( ) :

157 s e l f . g ene r e ra t e ( s e s s i on , metr ic )

158 s e l f . changes . c l e a r ( )

159

160 i f s e l f . last_change + Globals .MINUTE <= Globals .TIME:

161 # Convergence t e s t

162 i f s e l f . last_change + Globals .MINUTE == Globals .TIME:

163 # Just converged

164 s e l f . ca l cu late_used ( )

165 # t e l l the EWSD to proceed with normal opera t i on

166 return True

167

168 return False

42