The 77th NANOG meeting was held in Austin, Texas at the end of October and they invited Farsight’s Paul Vixie to deliver a keynote presentation. These are my thoughts in response to his presentation, and they are my interpretation of Paul’s talk and more than a few of my opinions thrown in for good measure!
In this article I'd like to look at one particular aspect of the Internet's inter-domain routing framework, namely the role of the Autonomous System (AS) Path in the operation of BGP, and in particular the use of AS Prepending.
Moving the DNS from the access ISP to the browser may not necessarily enhance open competition in the DNS world. In today's Internet just two browsers, Chrome and Safari dominate the browser world with an estimated 80% share of all users. If the DNS becomes a browser-specific setting, then what would that mean for the DNS resolver market? And why should we care? It would be useful to understand what is going on in the DNS today, before there has been any major shift to adopt DoH or DoT by high-use applications such as browsers. Can we measure the level of DNS centrality in the Internet today?
Stories of BGP routing mishaps span the entire thirty-year period that we’ve been using BGP to glue the Internet together. We’ve experienced all kinds of route leaks from a few routes to a few thousand or more. We’ve seen route hijacks that pass by essentially unnoticed, and we’ve seen others that get quoted for the ensuing decade or longer! After some 30 years of running BGP it would be good to believe that we’ve learned from this rich set of accumulated experience, and we now understand how to manage the operation of BGP to keep it secure, stable and accurate. But no. That's is not where we are today. Why is the task to secure this protocol just so hard?
It may sound a little esoteric, but after a recently exposed Linux vulnerability the setting of the MSS value in a TCP handshake evidently matters. What values are used out there in the Internet today?
At IETF 105, held in Montreal at the end of July, the Technical Plenary part of the meeting had two speakers on the topic of privacy in today's Internet, Associate Professor Arvind Narayanan of Princeton University and Professor Stephen Bellovin of Colombia University. They were both quite disturbing talks in their distinct ways, and I'd like to share my impressions of these two presentations and then consider what privacy means for me in today's Internet.
DNSSEC is often viewed as a solution looking for a problem. It seems only logical that there is some intrinsic value in being able to explicitly verify the veracity and currency of responses received from DNS queries, yet fleshing this proposition out with practical examples has proved challenging. Where else might DNSSEC be useful?
In June I participated in a workshop, organized by the Internet Architecture Board, on the topic of protocol design and effect, looking at the differences between initial design expectations and deployment realities. These are my impressions of the discussions that took place at this workshop.
The first RFC describing BGP, RFC 1105, was published in June 1989, thirty years ago. That makes BGP a venerable protocol in the internet context and considering that it holds the Internet together it's still a central piece of the Internet's infrastructure. How has this critically important routing protocol fared over these thirty years and what are its future prospects? It BGP approaching its dotage or will it be a feature of the Internet for decades to come?
The root zone of the DNS has been the focal point of many DNS conversations for decades. One set of conversations, which is a major preoccupation of ICANN meetings, concerns what labels are contained in the root zone. A separate set of conversations concern how this root zone is served in the context of the DNS resolution protocol. In this article I'd like to look at the second topic, and, in particular, look at two proposals to augment the way the root zone is served to the DNS.
From time to time the IETF seriously grapples with its role with respect to technology relating to users' privacy. Should the IETF publish standard specifications of technologies that facilitate third party eavesdropping on communications or should it refrain from working on such technologies? Should the IETF take further steps and publish standard specifications of technologies that directly impede various forms of third party eavesdropping on communications? Is a consistent position from the IETF on personal privacy preferred? Or should the IETF be as agnostic as possible and publish protocol specifications based solely on technical coherency and interoperability without particular regard to issues of personal privacy? This issue surfaced at IETF 104 in the context of discussions of DNS over HTTPS, or DOH.
Many aspects of technology adoption in the Internet over time show simple "up and to the right" curves. What lies behind these curves is the assumption that once a decision is made to deploy a technology the decision is not subsequently "unmade." When we observe an adoption curve fall rather than rise, then it’s reasonable to ask what is going on.
Quick UDP Internet Connection (QUIC) is a network protocol initially developed and deployed by Google, and now being standardized in the Internet Engineering Task Force. In this article we’ll take a quick tour of QUIC, looking at what goals influenced its design, and what implications QUIC might have on the overall architecture of the Internet Protocol.