In this post I would like to talk mainly about a document recently published by the IETF called Ethernet over HTTPS Protocol. I must confess that the title caught my attention.
History
The need to encapsulate one protocol in another is not new. In fact, this practice has been with us for approximately 30 years.
So, let’s go back to the 90s. Those were the years when ideas for encapsulating one protocol in another first came up. For example, IP-IP (IP in IP) appeared when the Internet was in its early stages of commercial expansion and people were trying to find ways to connect private networks over public network infrastructure, what we now know as the Internet.
Other technologies emerged during that decade that are still very popular today, including dear old GRE, PPTP, and L2TP. In the late 90s and early 2000s, there were even significant advances in IPSEC VPNs.
But let’s not jump forward so much and instead stay in the 90s for a bit longer. Not only did people want to encapsulate IPv4 in IPv4, but they also took a step forward with IPv6 and protocol 41 (IPv6 in IPv4) was born in 1998.
(Free access, no subscription required)
The rest, as they say, is history. Any number of “mixtures” of protocol encapsulations have already been developed, such as IPv4 over IPv6, IPv6 over UDP over IPv4, Ethernet over IP, and a long etcetera.
Ok, let’s get back to the Ethernet over HTTPS draft.
At the end of 2023, specifically on 27 December, a draft arrived at the Internet Area Working Group (INTAREA) with the title Ethernet over HTTPS.
The rest, as they say, is history. Any number of “mixtures” of protocol encapsulations have already been developed, such as IPv4 over IPv6, IPv6 over UDP over IPv4, Ethernet over IP, and a long etcetera.
Ok, let’s get back to the Ethernet over HTTPS draft.
At the end of 2023, specifically on 27 December, a draft arrived at the Internet Area Working Group (INTAREA) with the title Ethernet over HTTPS.
What is this draft about?
The document seeks to define a protocol to encapsulate Ethernet frames over HTTPS, allowing secure communication between a client and internal web servers.
How is this to be achieved?
Section 1.2 of the draft presents an explanation that can be summarized as follows:
By specifying an internal URL, the client recognizes that Ethernet over HTTPS should be used for communication. The client browser, pre-configured with the IP address and port of the HTTP Server acting as the gateway to the LAN, initiates the Ethernet-over-HTTPS protocol and sends an authentication request to the server. Once authenticated, the client sends an Ethernet frame encapsulated within an HTTPS request for an internal webpage. The server decapsulates the Ethernet frame, extracts the original HTTP request, and routes it to the internal web server. The server then encapsulates the response from the internal web server and sends it back to the client.
The draft addresses an interesting topic, may be considered novel, and can have multiple implementations.
At the moment, it is a brief draft and correctly emphasizes security and authentication.
Doubts raised by the draft
The problem is not well defined, it is difficult to understand why it wants to solve a situation at the HTTP level using Ethernet frames.
It appears that the EoH server is similar to a proxy.
Security at the Layer 2 level is very delicate and should at least be mentioned in the draft.
The draft presents examples using IPv4 mac_address and IP_address ☹️
The explanation of how the protocol works undeniably leaves many doubts.
It is very normal in the world of encapsulation to have concerns about excess payload. Transporting Ethernet over HTTPS literally means loading the entire TCP/IP model into HTTPS.
To the previous item we must add potential MTU issues that this type of solution may entail.
Work has already been done in this sense, including the draft titled “Proxying Ethernet in HTTP” and a software called Softether that does exactly what the draft promises to do. And all of this without mentioning “Proxying IP in HTTP” which is already an Standards Track RFC (RFC 9484).
Predictions about the draft
Let’s recall how the IETF works (see diagram below). One or more individuals propose a draft, it is then adopted by the Working Group, and after several stages of community consensus it is adopted as an RFC.
The IETF Publication Process
In its current version, it appears that the draft will not advance much. I believe it will not reach consensus within the IETF. Currently, it seems that there is not much support from the community. However, I wouldn’t want to completely rule this out, as something could happen that might turn things around, such as adding new authors, achieving running code, in-person presentations, among many other possibilities.
Conclusions
This draft proposes a risky idea—let’s call it thoughtful—without a clear problem to solve. This is an obvious clear example that not all documents that reach the IETF are very elaborate. Sometimes they are merely ideas to take the temperature of the community.
What are your thoughts about this draft? Would you like to submit a document to the IETF?
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
