In the past few weeks, I’ve been learning more about macro-level steps to secure the global Internet’s control plane from a BGP routing perspective. The perspective of this new technology — RPKI and BGPSEC combined with DNSSEC — and another new technology called DANE presents an opportunity to secure the Internet’s most basic control plane functions.
To be perfectly clear, when I say “Control Plane of the Internet,” I’m referring to the core protocols used to route and direct traffic between networks on the Internet, specifically Border Gateway Protocol (BGP) and the Domain Name System (DNS). Given the recent NANOG 52 meeting in Denver, CO, it’s timely to provide a quick overview of these technologies and how they may be leveraged in the future.
Resource Public Key Infrastructure (RPKI)
The development and adoption of a globally consistent RPKI will allow network operators to consistently validate the origin of BGP routing announcements. By validating the origin of a BGP routing announcement (prefix), networks can ensure that the penultimate destination of IP traffic is who they claim to be and that the destination network is a 100% authorized and valid receiver of that traffic.
Ultimately, this prevents a comment threat known as Prefix Hijacking — a topic we examined at NANOG 46 and commonly known as the causal factor behind the now famous Pakistan/Youtube hijacking. Malicious or operator caused, the RPKI can help to prevent these events from occurring in the future. Here’s more about the RPKI project.
BGP Security (BGPSEC)
By using RPKI, we can now validate the origin of every prefix in the global routing table. By adding an additional layer of security called BGP Security Extensions (BGPSEC), we can validate every interim network AS hop that a BGP prefix announcement traverses. To do this, routers on each interim AS hop will cryptographically sign each announcement as it is passed along the BGP path. If a prefix is passed to a router that isn’t support to receive that particular announcement, the receiving router will be unable to decrypt the announcement and use it in calculating its routing tables.
This future technology can be used to protect against Kapela/Pilosov path shortening/man-in-the-middle attacks. At NANOG, Randy Bush from IIJ gave us the rundown on BGPSEC, while Sharon Goldberg of Boston University presented a model on how to deploy BGPSEC in a market-driven deployment. The combination of RPKI, Origin Validation and BGPSEC gives network operators the ability to secure one of two Internet control planes. In this case, BGP routing.
DNS Security Extensions (DNSSEC)
On the DNSSEC front, the root zone has been signed for almost a year, multiple registries have signed their zones and are accepting trust anchors, some customers are signing their zones and work is being done at the operating system level to validate DNSSEC information as it is retrieved. Overall, DNS administrators are becoming more familiar with operating and institutionalizing DNSSEC management practices within their organizations, including those using Dyn’s automated DNSSEC management functions.
In fact, the IANA DNSSEC management practice for the root KSK completed a Systrust Audit, signifying that the operational procedures used to manage the root KSK are well implemented and soundly utilized. More work needs to be done educate DNS administrators about DNSSEC, how to sign their zones, manage trust anchors and how to setup secure, validating recursive resolvers.
With a complete, end to end deployment of DNSSEC, from authoritative to recursive to end-host, the DNS control plane becomes secured. This effort thwarts against DNS pharming and poisoning attacks, and certain phishing attacks. It becomes harder to trick grandma into going to the wrong site.
Seeing that DNS is the world’s largest, globally distributed, eventually consistent database in existence, the addition of DNSSEC adds encryption and validation to this incredibly versatile resource. The ability to leverage the DNS in future security applications is nearly unlimited.
DNS-based Authentication of Named Entities (DANE)
On the HTTP data plane, we’ve all been using technologies such as Transport Layer Security (TLS) and Secure Sockets Layer (SSL) to authenticate and encrypt the transport of sensitive user information, such as usernames, passwords, and billing information. In X.509 certificates (the certificates used in TLS and SSL) the subject of the certificate is generally populated with the DNS FQDN of the service to be secured. During the TLS/SSL negotiation process, DNS look-ups are performed to validate the FQDN of the requested service and the FQDN encoded in the subject of the certificate. It’s a difficult hack, but if an attacker can obtain a forged, yet well trusted certificate and perform a DNS pharming attack at the same time, there’s nothing preventing your browser from believing that it is connected to the right host.
DANE aims to secure this well known weakness in TLS/SSL negotiation by using DNSSEC to verify the DNS FQDNs of requested service and the FQDN presented in the SSL certificate. Additional signaling information, such as which SSL CAs should be trusted for the FQDN/service pair, can be reliably transmitted using DNSSEC. In fact, even the CA certificate and service certificate can be delivered and validated using DNSSEC, ensuring 100% secure TLS/SSL negotiation.
What does this all mean?
These recent technology developments will ultimately help secure the critical control and signaling pathways used today on the Internet. When you type http://dyn.com/ into your browser in a DANE + DNSSEC + BGPSEC + RPKI enabled environment, you will be able guarantee the following:
- Using DANE, validate that the SSL CA presented in the certificate is the one we want you to validate against and that you shouldn’t trust any other certificate CA with information about www.dyndns.com.
- Using DANE and DNSSEC, validate that the DNS FQDN for www.dyndns.com is resolving to an IP address controlled by Dyn and that the SSL certificates subject name is DNSSEC validated to match to our organization.
- Using DNSSEC, validate that the DNS transport path and corresponding data from our network of 17 globally anycast locations has not been tampered with while in transit and therefore you have decided to connect to the correct IP address for www.dyndns.com.
- Via BGPSEC, know that the forward path taken by your DNS and HTTP packets was not hijacked by a man-in-the-middle attack.
- And lastly, via RPKI and prefix origin validation, that the penultimate destination of your DNS and HTTP traffic was an prefix and origin pair authorized to exist on the Internet and that the IP resources allocated to Dyn where not being originated by an unauthorized third party.
As a user, with a complete end-to-end deployment, you would be able to validate every element of the control and encryption paths utilized to form your secure connection to https://www.dyndns.com. In many cases, some of this technology is incredibly early in implementation and deployment, specifically RPKI, BGPSEC, and others are still experimental, specifically DANE.
It is Dyn’s position to keep abreast of these technologies, implement them on our own network when fully tested and considered of production quality, and furthermore to provide useful means of leveraging these technologies to our DNS and email customers as soon as is reasonably possible. As a society who becomes more dependent on the Internet everyday, it is our responsibility as technology stewards to ensure that people continue to trust the protocols and systems that the Internet are built upon.