379 research outputs found

    BGP-XM: BGP eXtended Multipath for Transit Autonomous Systems

    Get PDF
    Multipath interdomain routing has been proposed to enable flexible traffic engineering for transit Autonomos Systems (ASes). Yet, there is a lack of solutions providing maximal path diversity and backwards compatibility at the same time. The BGP-XM (Border Gateway Protocol-eXtended Multipath) extension presented in this paper is a complete and flexible approach to solve many of the limitations of previous BGP multipath solutions. ASes can benefit from multipath capabilities starting with a single upgraded router, and without any coordination with other ASes. BGP-XM defines an algorithm to merge into regular BGP updates information from paths which may even traverse different ASes. This algorithm can be combined with different multipath selection algorithms, such as the K-BESTRO (K-Best Route Optimizer) tunable selection algorithm proposed in this paper. A stability analysis and stable policy guidelines are provided. The performance evaluation of BGP-XM, running over an Internet-like topology, shows that high path diversity can be achieved even for limited deployments of the multipath mechanism. Further results for large-scale deployments reveal that the extension is suitable for large deployment since it shows a low impact in the AS path length and in the routing table size

    Multi-path BGP: motivations and solutions

    Get PDF
    Although there are many reasons towards the adoption of a multi-path routing paradigm in the Internet, nowadays the required multi-path support is far from universal. It is mostly limited to some domains that rely on IGP features to improve load distribution in their internal infrastructure or some multi-homed parties that base their load balance on traffic engineering. This chapter explains the motivations for a multi-path routing Internet scheme, commenting the existing alternatives and detailing two new proposals. Part of this work has been done within the framework of the Trilogy research and development project, whose main objectives are also commented in the chapter.Part of this work has been done within the framework of the Trilogy research and development project. The different research partners of this project are: British Telecom, Deutsche Telekom, NEC Europe, Nokia, Roke Manor Research Limited, Athens University of Economics and Business, University Carlos III of Madrid, University College London, Universit Catholique de Louvain and Stanford University.European Community's Seventh Framework ProgramEn prens

    Design of a Scalable Path Service for the Internet

    Get PDF
    Despite the world-changing success of the Internet, shortcomings in its routing and forwarding system have become increasingly apparent. One symptom is an escalating tension between users and providers over the control of routing and forwarding of packets: providers understandably want to control use of their infrastructure, and users understandably want paths with sufficient quality-of-service (QoS) to improve the performance of their applications. As a result, users resort to various “hacks” such as sending traffic through intermediate end-systems, and the providers fight back with mechanisms to inspect and block such traffic. To enable users and providers to jointly control routing and forwarding policies, recent research has considered various architectural approaches in which provider- level route determination occurs separately from forwarding. With this separation, provider-level path computation and selection can be provided as a centralized service: users (or their applications) send path queries to a path service to obtain provider- level paths that meet their application-specific QoS requirements. At the same time, providers can control the use of their infrastructure by dictating how packets are forwarded across their network. The separation of routing and forwarding offers many advantages, but also brings a number of challenges such as scalability. In particular, the path service must respond to path queries in a timely manner and periodically collect topology information containing load-dependent (i.e., performance) routing information. We present a new design for a path service that makes use of expensive pre- computations, parallel on-demand computations on performance information, and caching of recently computed paths to achieve scalability. We demonstrate that, us- ing commodity hardware with a modest amount of resources, the path service can respond to path queries with acceptable latency under a realistic workload. The ser- vice can scale to arbitrarily large topologies through parallelism. Finally, we describe how to utilize the path service in the current Internet with existing Internet applica- tions

    The Maestro Attack: Orchestrating Malicious Flows with BGP

    Get PDF
    We present the Maestro Attack, a Link Flooding Attack (LFA) that leverages Border Gateway Protocol (BGP) engineering techniques to improve the flow density of botnet-sourced Distributed Denial of Service (DDoS) on transit links. Specific-prefix routes poisoned for certain Autonomous Systems (ASes) are advertised by a compromised network operator to channel bot-to-bot ows over a target link. Publicly available AS relationship data feeds a greedy heuristic that iteratively builds a poison set of ASes to perform the attack. Given a compromised BGP speaker with advantageous positioning relative to the target link in the Internet topology, an adversary can expect to enhance flow density by more than 30 percent. For a large botnet (e.g., Mirai), the bottom line result is augmenting the DDoS by more than a million additional infected hosts. Interestingly, the size of the adversary-controlled AS plays little role in this effect; attacks on large core links can be effected by small, resource-limited ASes. Link vulnerability is evaluated across several metrics, including BGP betweenness and botnet flow density, and we assess where an adversary must be positioned to execute the attack most successfully. Mitigations are presented for network operators seeking to insulate themselves from this attack
    • …
    corecore