Project topics and materials
Get Complete Project Material File(s) Now! »
Routing Information Base and Routing Table
In BGP, routes are pairs composed of a set of IP prexes and a number of attributes associated with the destination(s). These routes are stored in the RIB (Routing Information Base), which is composed of three distinct elements that contain routing information:
The Adj-RIB-In, i.e. the incoming adjacent RIB. There is one Adj-RIB-In per BGP peer. It contains the unprocessed routes received from that peer, i.e. using that peer as the next-hop router.
The Adj-RIB-Out, i.e. the outgoing adjacent RIB. There is one Adj-RIB-Out per BGP peer. It contains the routes that the BGP router is willing to announce to its peer, according to its internal policy.
The Loc-RIB, i.e. the local RIB. There is one unique Loc-RIB in the router. This table contains the routes selected by applying the route selection process to all of the Adj-RIB-In. The routing table, or, equivalently, the forwarding table, contains the information necessary for the BGP router to forward packets. It is not part of the RIB, but is built upon the data contained in the RIB. More precisely, it is a combination of static routes congured on the router, routes learnt via an interior gateway protocol (i.e. from within the AS), and routes learnt from BGP. The way these elements are combined into the routing table is also part of the internal policy of the BGP router.
Decision Process and Route Selection
This Section details the processes that update the RIB and the routing table when an update message is received.
First, all withdrawn routes are processed by removing the route from the peer’s Adj-RIB-In. Then, the updated routes are processed. The updated part of the update message either contain a new route, or an existing route with a new set of attributes. If the route is new, it is inserted in the peer’s Adj-RIB-In. If the route already exists in the peer’s Adj-RIB-In, it is replaced by the incoming route. This eectively enables BGP routers to change route attributes without having to explicitly withdraw them rst. Once the Adj-RIB-In has been modied, the decision process is started. Its goal is to select the best route available for each destination, while, at the same time, enforcing the router’s local policy. The decision process happens in three phases.
Phase 1 computes the degree of preference for each route in the Adj-RIB-In and its feasibility. [RFC4271] does not dene the exact process that should be used to compute the preference of a route, but denes the characteristics of an abstract preference function that is able to enforce a local policy. Router vendors, on the other hand, implemented it as a set of procedures which take into account multiple variables [van Beijnum 2002]. The local policy can be dened by changing the values of these variables and the way they relate to one another. Since this implementation is vendor-specic, it is hard to describe, but it generally comes down to preferring routes with a shorter AS path and a lower multi-exit discriminator. In order to illustrate a vendor-specic variable, Cisco IOS attributes a weight to a route, preferring routes with a heavier weight.
Prex Hijacking
Prex hijacking (also known as BGP hijacking or IP hijacking) is the act of absorbing (a part of) the trac destined to another AS through the propagation of erroneous BGP routes, which is possible because of the implied mutual trust among BGP routers. It can be the result of routers miscongurations [Mahajan et al. 2002] or malicious intents [Ballani et al. 2007; Hu et al. 2007; Qiu et al. 2007; Tahara et al. 2008; Butler et al. 2010].
Regardless of the intentions of the issuer of the incorrect routes, we will refer to them as the hijacking AS. In the same fashion, the route propagated by the hijacking AS is the hijacked route. The network whose route has been hijacked will be referred to as the victim AS. The correct route to the victim AS is referred to as the legitimate route (or the original route). By hijacking a prex, an attacker may [Zheng et al. 2007]
create a black hole in the network (by simply dropping the packets);
steal the victim AS’s identity by imitating the victim’s services (e.g. duplicate website);
intercept the trac to eavesdrop (or record) the exchanged data and then forward the data back to the victim AS.
send spam, and/or carry out other malicious activity.
In this Section, we rst present of taxonomy of prex hijacking which denes the possible vectors to carry out such an attack. We then provide an overview of some large-scale hijacks.
Table of contents :
1 Introduction
1.1 The Internet and the Border Gateway Protocol
1.2 Prex Hijacking
1.3 Contributions
1.4 Collaboration
1.5 Roadmap
2 BGP and Prex Hijacking
2.1 The Border Gateway Protocol
2.1.1 Introduction
2.1.2 IP Prexes
2.1.3 AS Numbers
2.1.4 Routing Information Base and Routing Table
2.1.5 BGP Messages
2.1.6 Decision Process and Route Selection
2.1.7 Trac Forwarding
2.1.8 Mutual Trust
2.2 Prex Hijacking
2.2.1 Taxonomy of Prex Hijacking
2.2.2 Occurrences of Prex Hijacking
2.3 Securing BGP
2.3.1 Securing BGP Sessions
2.3.2 BGP Ingress Filtering
2.3.3 Securing the Routing Information
2.4 Detecting Prex Hijacking
2.4.1 Control Plane Techniques
2.4.2 Data Plane Techniques
2.4.3 Combining the Control Plane and the Data Plane
2.4.4 Discussion
2.5 Accessing BGP Data
2.5.1 Looking Glasses
2.5.2 Raw Data
2.5.3 BGPmon: BGP Monitoring System
2.6 The Internet Routing Registries
2.7 Summary and Conclusion
3 Multiple Origin AS Prexes
3.1 Introduction
3.2 Related Work
3.3 Methodology and Dataset
3.3.1 Denitions
3.3.2 BGP Dataset
3.4 A Longitudinal Study of MOAS Prexes
3.4.1 General Results
3.4.2 MOAS Patterns
3.4.3 Evolution Over Time
3.5 MOAS Filtering: Building a Suspicious MOAS Dataset
3.6 Analyzing Suspicious MOASes
3.7 Case Study: The Bulgarian Case
3.7.1 First Examination
3.7.2 Second Examination
3.7.3 Discussion
3.8 Summary and Conclusion
4 Overlapping Prexes
4.1 Introduction
4.2 Related Work
4.3 Methodology and Datasets
4.3.1 IRR Databases
4.3.2 BGP Data
4.3.3 Denitions
4.3.4 Metrics
4.4 Behind IP Prex Overlaps
4.4.1 BGP vs IRR Databases
4.4.2 Children and Subfamilies
4.4.3 AS-Level Topology
4.4.4 Real-World Case Studies
4.5 Validating Sub-MOAS Announcements
4.5.1 Architecture
4.5.2 Results
4.6 Summary and Conclusion
5 The IP Blackspace
5.1 Introduction
5.2 Isolating the Blackspace
5.2.1 IP Space Assignation Hierarchy
5.2.2 Denitions
5.2.3 Internet Routing Registries
5.2.4 RIR Statistics Files
5.2.5 Blackspace Computation Process
5.3 Blackspace Analysis
5.3.1 Prevalence and Persistence
5.3.2 BGP Characterization
5.3.3 Data Plane and Application-Level Analysis
5.4 Discussion
5.5 Related Work
5.6 Summary and Conclusion
6 Conclusions and Future Perspectives
A Deceler les attaques par detournement BGP : synthese
Bibliography
