During the joint Internet Engineering Steering Group (IESG) and Internet Architecture Board (IAB) retreat on 15-17 May 2017, the group discussed a number of topics related to network operator activities for encrypted flows. As part of that conversation, the group looked at RFC 4084 (May 2005), which tackled the question, what does Internet access mean? A dozen years after its publication, the subject probably deserves a new look, and several of the folks at the retreat agreed to draft a new version for community review.
As one of those volunteers, I’d like to dive into RFC 4084 and share what may have changed since it was written. After walking through the need to avoid pejorative terms, the RFC sets out the following types of connectivity: web connectivity, client connectivity only with no public address, client connectivity only with a public address, firewalled Internet connectivity, and full Internet connectivity.
For those who have bought enterprise connectivity recently, it’s obvious that several common categories are missing, including dark fiber, lit service connectivity to a home office, and managed MPLS tunnels, to name a few. More important, however, the RFC doesn’t really touch on cellular wireless connectivity, which is now one of the most common ways people connect to the Internet. This means that it also doesn’t touch on topics like data caps, roaming for data services, zero rating, and data compression proxies. For cellular connectivity, these topics can be the key to understanding the trade-offs in connectivity, privacy, and costs for a particular service offering.
Beyond the proliferation in available offerings, there has been another major change: the ubiquity of filtering. RFC 4084 describes filtering at the ISP level in Section 3, and notes “the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services”. RFC 7754 (March 2016) provides a much more detailed description of blocking and filtering, and highlights restricting objectionable content as a category beyond blocking objectionable traffic that may be a requirement imposed by state regulators. In such jurisdictions, what RFC 4084 described as “full Internet connectivity” has disappeared, because service providers are required to prevent their customers from reaching specific Internet resources, services, or destinations. Even where blocks are not in place, regulatory increases in the amount of Internet tracking data retained and the length of time it is kept have become common. These may contribute to self-censorship in the use of some content. Simply put, firewalled Internet connectivity has become the default offering required of service providers within those territories.
In addition, RFC 4084 describes Internet connectivity in terms that apply to the services that are consumed by a human user and, although some social networking and streaming services are absent, it remains generally useful in that regard. As we move into an era in which devices talk to other devices, we need to examine what a service provides for traffic among devices or between devices and back-end services. Is the implication of a web-only service that the Internet of Things is not supported, or is the implication that it must be reached by a web-based gateway or proxy? The difference between those two scenarios is a topic of serious contemplation today, and the architecture of a number of future services may depend on it.
In many cases, the architecture of the Internet has developed in the course of a commercial dialog between network operators’ offerings and consumers’ use. Many efforts to make cellular systems walled gardens failed, for example, because users simply weren’t willing to use them that way and wanted the broader connectivity of the Internet. As we look at this new tension among users’ desires for confidential communication, network operators’ management practices, and regulatory frameworks, a common vocabulary for the services available to users may help us understand what architectures we can build. If you’d like to contribute to the early discussion, [email protected] is one place to start.