In the last 15 years, the Internet’s architecture has continued to evolve organically. Despite this evolution, the classic TCP/IP stack is still used to describe and discuss Internet architecture.
In this post, my fellow researchers and I from the Polytechnic University of Catalonia and Cisco propose modifying the TCP/IP stack in order to accommodate such evolution. We introduce two variations of the classic TCP/IP stack — the L3-centric, based on the design of modern Software-Defined networks (such as Software-Defined WANs), and the L7-centric, inspired by the paradigms of Zero Trust networks and Service Meshes. We believe that these models are more representative of the status quo. Note that we are not presenting a new architecture but describing what is already out there.
Our goal is to trigger a discussion about changes and trends in the current Internet architecture.
What both of these models have in common is that they introduce two new layers to the stack — a security layer and an extension layer. The security layer is usually defined by standards like IPsec or TLS, and its main goal is to provide data confidentiality, with integrity, and some form of authentication. The extension layer carries information to provide additional functionalities; it is not necessarily standardized and depends on each vendor or application requirements. Some examples of extensions are the policy tags in modern SD-WANs, or the HTTP extensions used to identify the type of device in Zero Trust networks.
Architecture
Figure 1 presents a comparison of the classical TCP/IP stack with the proposed L3-centric and L7-centric. In both proposals, the physical, L2, and routing layers, HTTP, and application layers remain the same.
On the one hand, in the L3-centric model, we find the security header (L3 security in Figure 1) directly after the IP header. Some protocols that implement this header are the widely-used IPsec, or more recently, the WireGuard VPN. Immediately after this header, the extension header (L3 extensions in Figure 1) provides additional functionalities, such as a VPN identifier to provide network isolation, or group tags, present in commercial SD-WANs. Next, we find the original IP datagram that was encapsulated by the security layer (containing another IP header), the transport protocol header, and the application data.
On the other hand, most of the new headers are higher in the stack in the L7-centric stack. The security header (Transport Security in Figure 1) is just after the transport header, usually in the form of TLS. After that, we find a HTTP header, followed by several HTTP extensions that correspond to the extension header. It should be noted that this header is not necessarily standardized, unlike the security header. It can carry information for multiple purposes, like identity, Quality of Experience (QoE), policy labels, and so on. For example, Service Meshes make use of these extensions to perform advanced traffic management based on the URL of the HTTP flow. Last in this stack is the application data.
Case studies
Here are two examples of the previous stacks found in solutions that are already deployed: SD-WANs as an example of the L3-centric stack, and Service Meshes as an example of the L7-centric stack.
SD-WANs
Commercial SD-WANs are ubiquitous nowadays (PDF). We can find both the security and the extension headers following the L3-centric stack in their design. In this case, the security header often appears in the form of IPsec in tunnel mode, or equivalent L3 security protocols. For extension headers, it is common for these systems to add an additional header directly after the security header (L3 extensions in Figure 1). This header can be used for different purposes, the most common being isolation — creating isolated VPNs for security reasons. Other use cases are bandwidth aggregation, redundancy, multicast, and so on. A classical example of this header is VXLAN (RFC 7348), or Multiprotocol Label Switching (MPLS) labels.
Service Meshes
Service Meshes are used to connect applications running inside containers in large-scale data centres (PDF). Their key component has traditionally been the sidecar proxy, a HTTP proxy that intercepts all communications between applications, monitors their status, and enforces policies. Here, the security header is the TLS protocol, since all connections leverage HTTP between the proxies. Some of them use mutual TLS to authenticate both ends of the connection.
Next, the extension header is based on custom HTTP extensions that allow enforcing complex traffic management at the application level, such as routing a HTTP flow based on its URL, A/B testing, or canary releases, among others. Finally, note that although Service Meshes are currently restricted to data centres, this could change with Envoy Mobile since it can be deployed in end-hosts.
Conclusion
In this post, we have proposed adding two additional headers to the classical TCP/IP stack, in order to accommodate what we’ve seen in the evolution of the Internet architecture in the last 15 years. We presented a formalization of this architecture by adding these two additional layers to the TCP/IP protocol stack.
Our research paper ‘A Reflection on the Organic Growth of the Internet Protocol Stack‘ aims to trigger a discussion about changes to the current Internet architecture. Please share your thoughts in the comments below.
Jordi Paillissé is a postdoctoral researcher in the Barcelona Neural Networking Center, at BarcelonaTech — the Polytechnic University of Catalonia, working at the intersection of computer networks and machine learning. His main research interests are network modeling, future Internet architectures, Software-Defined Networking and blockchain applications for the Internet.
This post and paper were co-authored by Alberto Rodríguez-Natal, Fabio Maino, and Albert Cabellos.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.