Thirty years of changes and evolution of Internet core protocols

When the Internet began to be widely used in the 1990s, most of its communications used only a few protocols: IPv4 protocol routed the packets, TCP protocol forwarded the packets to the connection, SSL (and later TLS) protocol encrypted the connection, DNS protocol named the hosts to be connected, and HTTP protocol was the most commonly used application protocol.

Over the years, these core Internet protocols have changed very little: HTTP has added a few new headers and request methods, TLS has slowly made small changes, TCP has tweaked congestion control, and DNS has introduced features like DNSSEC. These protocols have seemed to stay the same for a long time (except for IPv6, which has attracted a lot of attention from network operators).

[[214083]]

As a result, network operators, vendors, and policymakers who wish to understand (and sometimes control) the Internet adopt practices based on the way these protocols are designed to work—whether they are intended to debug problems, improve service quality, or impose policy.

Major changes to the core Internet protocols are starting to happen now. While they are intended to be compatible with most of the Internet (because, if they weren't, they wouldn't be adopted), they may break things that are not specified in the protocols, or that simply assume that changes don't exist.

Why we need to change the Internet

There are a number of factors driving these changes.

First, the limitations of core Internet protocols are becoming increasingly apparent, especially when it comes to performance. Due to structural issues in both applications and transport protocols, the network is not being used efficiently, resulting in end-users seeing substandard performance (particularly, network latency).

This means that there is a strong incentive to evolve or replace these protocols, as there is a lot of experience showing that even small performance improvements can make a difference.

Second, the ability to evolve Internet protocols—at any level—becomes more difficult over time, primarily because of the unintended uses of the network discussed above. For example, HTTP proxy servers that attempt to compress responses make it more difficult to deploy new compression techniques; TCP optimizations in middleboxes make it increasingly difficult to deploy improvements to TCP.

Finally, we are in the midst of a shift in the internet towards increasing use of encryption, first sparked by the Edward Snowden revelations in 2015. That is a separate discussion, but related to this is that encryption is one of the best tools out there, and we have to make sure the protocols evolve.

Let’s look at what happened, what’s coming next, how it affects the network, and how it affects the design of network protocols.

HTTP/2

HTTP/2 (based on Google's SPDY) was the first major change - it was standardized in 2015. It multiplexes multiple requests onto a single TCP connection, thus avoiding clients queuing requests without blocking each other. It is now widely deployed and supported by all major browsers and web servers.

From a networking perspective, HTTP/2 brings some significant changes. First, it is a binary protocol, so any device that assumes it is HTTP/1.1 will have problems.

This breaking problem was one of the main reasons for another major change in HTTP/2: it actually requires encryption. The benefit of this change is to avoid man-in-the-middle attacks from pretending to be HTTP/1.1, or more subtle things like stripping headers or blocking new protocol extensions - both of which came up during the engineers' development of the protocol, causing obvious support issues.

When it is encrypted, HTTP/2 requests also require the use of TLS/1.2, and blacklist some cipher suites that have been proven to be insecure - the effect is that only ephemeral keys are allowed. For potential impacts, see the relevant section on TLS 1.3.

Finally, HTTP/2 allows requests from multiple hosts to be coalesced into a single connection, improving performance by reducing the number of connections used for page loads (thus reducing congestion control scenarios).

For example, you can establish a connection to www.example.com and use that connection for requests to images.example.com. Future extensions to the protocol will allow other hosts to be added to a connection, even if they were not listed in the TLS certificate originally used for them. Therefore, the assumption that communication on a connection is limited to its initial purpose does not apply.

It is worth noting that despite these changes, HTTP/2 has not had significant interoperability issues or conflicts with the network.

TLS 1.3

TLS 1.3 has just passed the final stages of standardization and is already supported by some implementations.

Don't be fooled by the name, which simply increments the version number; it's actually a new TLS version, with a completely redesigned 'handshake' mechanism that allows application data to flow from scratch (often referred to as '0RTT'). The new design relies on ephemeral key exchanges, which eliminates the need for static keys.

That's causing concern among some network operators and providers -- especially those who need to have a clear picture of what's happening inside those connections.

For example, consider a bank data center with a regulatory requirement for visibility. By sniffing traffic packets on the network and decrypting it using static keys on their servers, they can log legitimate traffic and identify harmful traffic, whether it be an attack from the outside or an employee exfiltrating data from the inside.

TLS 1.3 doesn't support those specific techniques for eavesdropping on communications, because that's also a form of attack that ephemeral keys protect against. However, this puts network operators in an awkward position because they have regulatory requirements to use more modern encryption protocols and monitor their networks.

There is much debate about whether static keys should be required, whether alternatives are valid, and whether weakening the security of the entire Internet for the sake of a relatively small number of networks is the right solution. It is still possible to decrypt communications using TLS 1.3, but you need access to ephemeral keys to do so, and, by design, they cannot exist for long.

At this point, TLS 1.3 doesn’t look like it will change to accommodate these networks, however, there have been some rumors about creating another protocol that would allow third parties to snoop on communications, or do more. Whether this gets traction remains to be seen.

QUIC

Similar inefficiencies with TCP are evident in the HTTP/2 work. Since TCP is an in-order protocol, the loss of a packet can prevent subsequent buffered packets from being delivered to the application. For a multiplexed protocol, this has a significant impact on performance.

QUIC attempts to address this effect by refactoring TCP semantics (and parts of the HTTP/2 streaming model) on top of UDP. Like HTTP/2, it started as a Google effort and has now been accepted by the IETF as an initial use case for HTTP-over-UDP, with the goal of becoming a standard by the end of 2018. However, because Google has already deployed QUIC in the Chrome browser and on its website, it already accounts for more than 7% of Internet traffic.

Besides the massive shift in traffic from TCP to UDP (and the possible network adjustments that implies), both Google QUIC (gQUIC) and IETF QUIC (iQUIC) require full encryption; there is no such thing as unencrypted QUIC.

iQUIC uses TLS 1.3 to establish keys for the session, which are then used to encrypt each packet. However, because it is based on UDP, much of the session information and metadata that is exposed in TCP is encrypted in QUIC.

In fact, iQUIC currently uses a 'short header' for all packets except the handshake, exposing only a packet number, an optional connection identifier and a status byte, like the encryption key rotation schedule and the packet bytes (which may also eventually be encrypted).

Everything else is encrypted - including the ACK, to increase the barrier to traffic analysis attacks.

However, this means that passively estimating RTT and packet loss by observing connections is no longer feasible; there is simply not enough information. This lack of observability has caused a lot of concern among some operators, who believe that passive measurements like this are critical to debugging and understanding their networks.

One proposal they have to meet this need is the 'Spin Bit' - a bit in the packet header that flips back and forth, so that it is possible to estimate the RTT by observing it. Because it is decoupled from the application's state, its presence does not leak any information about the endpoint, nor does it allow for a rough estimate of the network position.

DOH

The change that is coming is DOH — DNS over HTTP. A large body of research shows that a common means of implementing policy intervention on the Internet is through DNS (whether on behalf of the network operator or a larger authority).

Using encryption to circumvent this control has been discussed for some time, however, it has a disadvantage (at least from some standpoints) - it may be treated differently from other communications; for example, access may be blocked by its port number.

DOH piggybacks DNS traffic onto an already established HTTP connection, thereby eliminating any discriminators. A network wishing to block access to the DNS resolver can only do so by blocking access to the website.

For example, if Google deployed its DOH-based public DNS service at www.google.com, and a user configured their browser to use it, a network wishing (or required) to have access to that service stopped would have to block all access to Google (kudos to them for providing a service!).

The DOH is just getting started, but it's already generating a lot of interest and has some anecdotal reports of deployments. It remains to be seen how networks (and government agencies) react to using DNS to enforce policy.

Rigidity and Lubrication

Returning to the motivations for protocol changes, there is a theme that runs through this work; an increasing number of problems that protocol designers encounter are assumptions that the network makes about how traffic is used.

For example, TLS 1.3 has some last-minute issues with middleboxes assuming it’s an older version of the protocol, and gQUIC blacklists several networks that throttle UDP traffic because those networks consider it harmful or low priority.

When a protocol is "frozen" in its extensibility points due to existing deployments, and thus cannot evolve, we say it has become ossified. The TCP protocol itself is an example of a serious ossification, so too many middlewares do too many things on top of the TCP protocol, such as blocking packets with unrecognized TCP options, or "optimizing" congestion control.

Preventing ossification is necessary to ensure that the protocol can evolve to meet the needs of the future Internet; otherwise, it will become a "public disaster" where the behavior of a few individual networks - while working well there - will affect the health of the entire Internet.

There are a number of ways to prevent ossification; if the data in question is encrypted, it cannot be accessed by any party other than those holding the key, preventing tampering. If the extension point is unencrypted, but is commonly used in a way that would clearly break the application (e.g., HTTP headers), it is unlikely to be tampered with.

Protocol designers must not artificially exploit an extension point by using cryptographic extension points in situations where they are not frequently used - we call this greasing it.

For example, QUIC encourages endpoints to use a range of decoy values ​​in version negotiation to avoid assuming that its implementation never changes (as is often the case with TLS implementations, leading to major problems).

Network and Users

Besides a desire to avoid ossification, these changes also reflect an evolving relationship between networks and their users. For too long, people have assumed that the web is always benevolent — or at least impartial — but that’s not always the case, not only with pervasive surveillance but also with attacks like Firesheep.

As a result, there is growing tension between the overall needs of Internet users and those networks when those networks want to access some of the user data flowing through their networks. Particularly affected are those networks that wish to enforce policy over their users; for example, corporate networks.

In some cases, they can achieve their goal by installing software (or a CA certificate, or a browser extension) on their users' machines. However, this is not easy in cases where the network does not own or have access to the computer; for example, BYOD is already common and IoT devices rarely have suitable control interfaces.

As a result, many discussions around protocol development in the IETF touch upon the sometimes competing needs of enterprises and other “leaf” networks, as well as the interests of the Internet as a whole.

participate

In order for the Internet to work better in the future, it needs to provide value to end users, avoid ossification, and keep the network running smoothly. The changes that are happening now need to meet all three goals, but people need more investment from network operators.

If these changes affect your network -- or don't -- please leave a comment below. Better yet, get involved in the IETF by attending meetings, joining mailing lists, or providing feedback on drafts.