The use of maxLength in the RPKI

This document recommends that operators avoid using the maxLength attribute when issuing Route Origin Authorizations (ROAs) in the Resource Public Key Infrastructure (RPKI). These recommendations complement those in [RFC7115].https://datatracker.ietf.org/doc/draft-yossigi-rpkimaxlen/First author draf

MaxLength considered harmful to the RPKI

User convenience and strong security are often at odds, and most security applications need to find some sort of balance between these two (often opposing) goals. The Resource Public Key Infrastructure (RPKI), a security infrastructure built on top of interdomain routing, is not immune to this issue. The RPKI uses the maxLength attribute to reduce the amount of information that must be explicitly recorded in its cryptographic objects. MaxLength also allows operators to easily reconfigure their networks without modifying their RPKI objects. Our network measurements, however, suggest that the maxLength attribute strikes the wrong balance between security and user convenience. We therefore believe that operators should avoid using maxLength. We give operational recommendations and develop software that allow operators to reap many of the benefits of maxLength without its security costs.https://eprint.iacr.org/2016/1015.pdfhttps://eprint.iacr.org/2016/1015.pdfPublished versio

Decentralized trust in the inter-domain routing infrastructure

Inter-domain routing security is of critical importance to the Internet since it prevents unwanted traffic redirections. The current system is based on a Public Key Infrastructure (PKI), a centralized repository of digital certificates. However, the inherent centralization of such design creates tensions between its participants and hinders its deployment. In addition, some technical drawbacks of PKIs delay widespread adoption. In this paper we present IPchain, a blockchain to store the allocations and delegations of IP addresses. IPchain leverages blockchains' properties to decentralize trust among its participants, with the final goal of providing flexible trust models that adapt better to the ever-changing geopolitical landscape. Moreover, we argue that Proof of Stake is a suitable consensus algorithm for IPchain due to the unique incentive structure of this use-case, and that blockchains offer relevant technical advantages when compared to existing systems, such as simplified management. In order to show its feasibility and suitability, we have implemented and evaluated IPchain's performance and scalability storing around 350k IP prefixes in a 2.5 GB chain.Peer ReviewedPostprint (published version

Optimization of BGP Convergence and Prefix Security in IP/MPLS Networks

Multi-Protocol Label Switching-based networks are the backbone of the operation of the Internet, that communicates through the use of the Border Gateway Protocol which connects distinct networks, referred to as Autonomous Systems, together. As the technology matures, so does the challenges caused by the extreme growth rate of the Internet. The amount of BGP prefixes required to facilitate such an increase in connectivity introduces multiple new critical issues, such as with the scalability and the security of the aforementioned Border Gateway Protocol. Illustration of an implementation of an IP/MPLS core transmission network is formed through the introduction of the four main pillars of an Autonomous System: Multi-Protocol Label Switching, Border Gateway Protocol, Open Shortest Path First and the Resource Reservation Protocol. The symbiosis of these technologies is used to introduce the practicalities of operating an IP/MPLS-based ISP network with traffic engineering and fault-resilience at heart. The first research objective of this thesis is to determine whether the deployment of a new BGP feature, which is referred to as BGP Prefix Independent Convergence (PIC), within AS16086 would be a worthwhile endeavour. This BGP extension aims to reduce the convergence delay of BGP Prefixes inside of an IP/MPLS Core Transmission Network, thus improving the networks resilience against faults. Simultaneously, the second research objective was to research the available mechanisms considering the protection of BGP Prefixes, such as with the implementation of the Resource Public Key Infrastructure and the Artemis BGP Monitor for proactive and reactive security of BGP prefixes within AS16086. The future prospective deployment of BGPsec is discussed to form an outlook to the future of IP/MPLS network design. As the trust-based nature of BGP as a protocol has become a distinct vulnerability, thus necessitating the use of various technologies to secure the communications between the Autonomous Systems that form the network to end all networks, the Internet

Design and implementation of InBlock, a distributed IP address registration system

The current mechanism to secure Border Gateway Protocol relies on the resource public key infrastructure (RPKI) for route origin authorization. The RPKI implements a hierarchical model that intrinsically makes lower layers in the hierarchy susceptible to errors and abuses from entities placed in higher layers. In this article, we present InBlock, a distributed autonomous organization that provides decentralized management of IP addresses based on blockchain, embedding an alternative trust model to the hierarchical one currently implemented by the RPKI. By leveraging on blockchain technology, InBlock requires consensus among the involved parties to change existent prefix allocation information. InBlock also fulfills the same objectives as the current IP address allocation system, i.e., uniqueness, fairness, conservation, aggregation, registration, and minimized overhead. InBlock is implemented as a set of blockchain smart contracts in Ethereum, performing all the functions needed for the management of a global pool of addresses without human intervention. Any entity may request an allocation of addresses to the InBlock registry by solely performing a (crypto) currency transfer to the InBlock. We describe our InBlock implementation and we perform several experiments to show that it enables fast address registering and incurs in very low management costs.Publicad

RiPKI: The Tragic Story of RPKI Deployment in the Web Ecosystem

Previous arXiv version of this paper has been published under the title "When BGP Security Meets Content Deployment: Measuring and Analysing RPKI-Protection of Websites", Proc. of Fourteenth ACM Workshop on Hot Topics in Networks (HotNets), New York:ACM, 2015Previous arXiv version of this paper has been published under the title "When BGP Security Meets Content Deployment: Measuring and Analysing RPKI-Protection of Websites", Proc. of Fourteenth ACM Workshop on Hot Topics in Networks (HotNets), New York:ACM, 2015Web content delivery is one of the most important services on the Internet. Access to websites is typically secured via TLS. However, this security model does not account for prefix hijacking on the network layer, which may lead to traffic blackholing or transparent interception. Thus, to achieve comprehensive security and service availability, additional protective mechanisms are necessary such as the RPKI, a recently deployed Resource Public Key Infrastructure to prevent hijacking of traffic by networks. This paper argues two positions. First, that modern web hosting practices make route protection challenging due to the propensity to spread servers across many different networks, often with unpredictable client redirection strategies, and, second, that we need a better understanding why protection mechanisms are not deployed. To initiate this, we empirically explore the relationship between web hosting infrastructure and RPKI deployment. Perversely, we find that less popular websites are more likely to be secured than the prominent sites. Worryingly, we find many large-scale CDNs do not support RPKI, thus making their customers vulnerable. This leads us to explore business reasons why operators are hesitant to deploy RPKI, which may help to guide future research on improving Internet security

Evaluation of the Deployment Status of RPKI and Route Filtering

The Border Gateway Protocol (BGP) is an essential infrastructure element, often termed “the glue that keeps the Internet together”. Even in its current version 4 , BGP misses essential security mechanisms that would allow to validate routing information distributed through BGP in terms of its authenticity and integrity. While mechanisms like BGPsec have been proposed many years ago, so far they have not found widespread adoption and many experts believe they never will due to their inherent complexity. To ensure a minimal level of protection, most Internet service providers (ISPs) rely on heuristic filtering of routing information advertised from neighboring autonomous systems (AS). One approach is called Path Origin Validation where an ISP tries to verify whether the AS advertising a certain IP prefix is actually the legitimate owner of this prefix

Lowering Legal Barriers to RPKI Adoption

Across the Internet, mistaken and malicious routing announcements impose significant costs on users and network operators. To make routing announcements more reliable and secure, Internet coordination bodies have encouraged network operators to adopt the Resource Public Key Infrastructure (“RPKI”) framework. Despite this encouragement, RPKI’s adoption rates are low, especially in North America.This report presents the results of a year-long investigation into the hypothesis—widespread within the network operator community—that legal issues pose barriers to RPKI adoption and are one cause of the disparities between North America and other regions of the world. On the basis of interviews and analysis of the legal framework governing RPKI, the report evaluates the issues raised by community members and proposes a number of strategies to reduce or circumvent the barriers that are material. The report also describes substantial action taken this year by the American Registry for Internet Numbers (“ARIN”) and other private organizations in light of public dialogue about RPKI