Our research agenda for improving routing security
A new line of research aimed on on extending BGP security
Chose your color
Frequently visited
Frequently asked questions
The Whois is an easy-to-use tool for checking the availability of a .nl domain name. If the domain name is already taken, you can see who has registered it.
On the page looking up a domain name you will find more information about what a domain name is, how the Whois works and how the privacy of personal data is protected. Alternatively, you can go straight to look for a domain name via the Whois.
To get your domain name transferred, you need the token (unique ID number) for your domain name. Your existing registrar has the token and is obliged to give it to you within five days, if you ask for it. The procedure for changing your registrar is described on the page transferring your domain name.
To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.
When a domain name is cancelled, we aren't told the reason, so we can't tell you. You'll need to ask your registrar. The advantage of quarantine is that, if a name's cancelled by mistake, you can always get it back.
One common reason is that the contract between you and your registrar says you've got to renew the registration every year. If you haven't set up automatic renewal and you don't renew manually, the registration will expire.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Would you like to be able to register domain names for customers or for your own organisation by dealing directly with SIDN? If so, you can become a .nl registrar. Read more about the conditions and how to apply for registrar status on the page becoming a registrar.
A new line of research aimed on on extending BGP security
The Border Gateway Protocol (BGP) and the DNS are two of the core protocols of the Internet. The DNS tells us where we can find services and information on the Internet, and BGP tells us how we can get there. Since SIDN’s role as a registry and DNS operator for the .nl top-level domain critically depends on BGP, we recently started an additional line of research on extending BGP security. In this blogpost, we discuss the three research topics we will focus on: the resilience of the infrastructure that provides the keying material for BGP security (RPKI), the deployment of BGP path security (BGPsec), and routing security for customer networks.
The current version of BGP is BGP4. It connects autonomously managed networks, called autonomous systems (ASes). BGP does so by propagating routing information through the Internet in a distributed and decentralised way. ASes establish peering relations between each other based on trust and economic incentives. The global exchange of routing information relies on the transitive trust that originates from those peering relations.
Every AS can claim new routes on the Internet, sometimes with disastrous consequences. For example, an AS can intentionally or accidentally claim that it is the origin of an IP address range or that it lies on a path towards a destination AS. Normally, it's not a problem that an IP address range can be announced from multiple ASes, because it allows the owner of a given prefix to migrate between ASes or distribute resources to increase resilience. However, the main problem here is that BGP in its most basic form does not enable an AS to check whether another AS is the rightful claimant to an IP prefix. Therefore, if such a claim is false, it might lead to the unavailability of the affected address range, and could enable the “hijacking” AS to eavesdrop on traffic sent towards IPs within the address range, or even to impersonate services.
Network operators implement filters to prevent false routing information from propagating. For example, they can make sure that they only accept routes from customers who are responsible for those routes. However, such filters are not always implemented correctly and are not sufficient because information often cannot be verified. Since the Internet relies on the correctness and stability of the information exchanged via BGP, the Internet community has developed several protocols that can improve the security of BGP and address the problems described. In this document, we briefly introduce the protocols in question, and we discuss where, in our opinion, research is needed to further improve the protocols and help their deployment.
The protocols discussed here rely on the Resource Public Key Infrastructure (RPKI), which allows owners of IP address space and ASes to make cryptographically verifiable claims about their resources, like IP addresses or AS numbers. You can find an overview of RFCs related to the RPKI here.
The first and most widely deployed objects in the RPKI are Route Origin Authorizations (ROAs), in which a resource owner cryptographically ties its prefix to a set of ASNs which are allowed to originate that prefix. All five Regional Internet Registries (RIR) support the creation of ROAs. ASes that validate and filter based on ROAs can prevent events where another AS falsely claims to be the origin of a prefix – a validation process which is called Route Origin Validation (RoV). The impact of this solution is, however, limited by the number of signed ROAs. Today, the number of ROAs is on the rise and the number of networks dropping prefixes that violate a ROA is increasing. Note that routers located at the edge of the Internet often need to rely on RoV implemented by their upstream providers because they do not receive the full BGP table and therefore cannot perform RoV.
Whereas ROAs associate IP prefixes with sets of originating AS numbers, Autonomous Systems Provider Authorization (ASPA) objects limit spoofing and impersonation of ASNs. ASPA is not yet standardised but is intended to enable ASes to publish in the RPKI through the provider AS that they use to connect to the rest of the Internet. Hence, ASPA can prevent an AS falsely claiming to be directly connected to an AS that publishes ASPA objects.
Finally, Border Gateway Protocol Security (BGPsec), standardised in RFC 8205, allows routers on the Internet to verify that received routing information was actually propagated via the claimed AS path. The router can then be sure that the path presented in the BGP update message actually exists. The system requires routers along the path to sign the BGP update with their private keys, including the signature of the previous BGP hop. That creates a chain of trust that enables routers to verify end-to-end AS paths. BGPsec requires network operators to publish the public keys of their routers in the RPKI.
The research community has come up with various measures for improving BGP security as well, for example BGP-iSec. However, there are no efforts to standardise them at the IETF, which reduces the chance of adoption. We don't therefore consider them in this blog.
We want to focus on three aspects of BGP security: the resilience of the RPKI, the deployment of BGPsec, and tools and insights that help operators to respond to hijacks. We believe that these aspects have not gotten enough attention or are so important for the security of the Internet that they deserve the attention of as many researchers as possible.
The RPKI is the foundation of ROAs and ASPA objects, amongst other things, and it plays an important role in BGPsec. The availability and resilience of the RPKI are therefore crucial. If RPKI information were unavailable for a longer period, parties might be unable to validate ROA and ASPA objects, receive updates or fetch router certificates. That would effectively negate the protection those protocols offer and prevent routes from propagating.
For example, a prefix owner who moves between ASes might be unable to update their corresponding ROA when the RPKI is unavailable. As a result, their ROA might become invalid and validating parties might drop routes towards the AS. With RoV being deployed at scale, such scenarios might have devastating effects on the availability of the Internet.
Our objective is to identify the critical components that can influence the availability of the RPKI, assess the likelihood and impact of an outage, and what it takes to increase the resilience of the RPKI.
Examples of research questions relating to RPKI resilience:
What components are responsible for the availability of RPKI?
What would the impact be if parts of RPKI or the whole infrastructure became unavailable?
What events could affect the availability of critical components and how likely are such events?
How can we prevent such events or reduce their impact?
To answer those questions, we will carry out Internet-wide measurements of the various RPKI components and their underlying dependencies.
Even though the RFCs standardising BGPsec are six years old, deployment of BGPsec remains almost non-existent. That is partly due to the chicken-and-egg problem that has haunted many security extensions to protocols in the past, such as DNSSEC.
Another reason is that the impact of BGPsec on route propagation is not well understood yet. A router sharing a route with a peer needs to sign the entire AS path in an announcement, and a router at the receiving end needs to verify that path. Those cryptographic operations can place a sizeable burden on the routers in question, especially where legacy equipment with limited processing capabilities is concerned.
Also, some BGP experts argue that BGPsec delivers the intended level of security only when it is fully deployed. Our goal is accordingly to understand how operators can achieve path security even if BGP is only partially deployed.
We have therefore formulated the following research questions:
What is the impact of BGPsec on the propagation of routes on the Internet?
If there is a negative impact, what causes the degradation in performance?
How can we reduce the performance impact?
Which ASes should adopt BGPsec to maximise the number of routes protected?
First and foremost, we want to answer those research questions by deploying and testing BGPsec in a local testbed at SIDN Labs. Recently, we also created our own test network located at Nikhef. This allows us to run BGPsec experiments with parties that share our interest in routing security research and would like to peer with us.
Most networks on the Internet are customer networks, meaning that they do not provide connectivity for other networks. These networks should protect their IP prefixes, for instance by publishing ROA or ASPA objects in the RPKI. However, not all networks on the Internet validate such objects and drop invalid announcements. Hence, ROA and ASPA objects cannot prevent all possible attacks.
Various tools are available to operators to detect the misuse of their own prefixes. Examples are route collectors or applications that build on route collectors, such as ARTEMIS. Although these tools are not perfect and might not be able to detect all events, they are relatively well studied. For that reason, our goal is to help operators whose prefixes are misused to assess the impact of hijacks and take the appropriate action.
To that end, we need to understand:
What patterns, if any, do hijacks follow; for example, how are they carried out and what actors are involved?
What is the impact of a hijack on the targeted operator's network and services?
If the impact is “significant” (depending on the operator and service), what action should an operator take to mitigate the impact?
What measures can operators take to increase the resilience of their networks and services against future hijacks?
In relation to those questions, we will draw on SIDN’s own experience as a stub network operator that provides critical services. Possible research products include recommendations for operators and metrics for measuring the impact of routing security on their services.
Have we missed important aspects? Do you want to collaborate on any of the topics mentioned above? We are interested receiving feedback from operators and researchers about our research agenda, and we invite you to contact us at moritz.muller@sidn.nl.
Acknowledgement: Thanks to our colleagues Jeroen Bulten and Dennis Meijer for their input.
Article by:
Share this article