Ethernet over HTTPS Protocol | Hacker News Reader

Ethernet over HTTPS Protocol

ietf.org

18 pointsshakna11 comments

A very incomplete RFC that I doubt will ever reach concensus based on this description.

Sending an ethernet frame one way and receiving an HTTP request back is just weird protocol design. It's also encoding HTTP while claiming to be ethernet based. There's no description for handling protocols like FTP/SMTP/IMAP traffic, let alone arbitrary traffic types. Of course this is to be expected, because ethernet is too low level a protocol to be practically pipeable over HTTP alone; there's no request/response structure, so the server wouldn't know what to send in response. I suppose server side events and pipelining/multiple channels could be used to transmit and receive messages asynchronously, but I feel like the HTTP stack is woefully underqualified for that kind of usage.

QUIC, on the other hand, could be useful for VPN style connections, and I can imagine a setup where a QUIC connection authenticates and then opens up separate channels to set up the VPN link, allowing for arbitrary data exchange as a result of an HTTPS request.

For something with such obvious security risks, you'd also expect at least a short summary of security challenges and required actions, but that seems to be missing.

I think this proposal was written by someone who was unaware of HTTP's CONNECT verb, which seems to do accomplish exactly what the author wants to accomplish (access an internal HTTP server externally, after authentication). There are advantages to using lower level frames (HTTP CONNECT lacks UDP support for protocols like QUIC, for example) but they're not actually leveraged here.

Perhaps the more interesting point of this proposal is that practically anyone can write an RFC proposal, you don't need the backing of a large company or a group of researchers. An RFC being hosted doesn't mean there's a new standard you need to keep track of, it only means someone sent the right messages to the right places to start the proposal process.

I think your qualification of this draft is quite mild.

I would rather say the author seems to misunderstand the functioning of pretty much every single protocol they mention in their draft, so I won’t be even starting to try to enumerate the shortcomings of the proposal, to me it has the same semantics as “let’s make ducks blue hats”. There’s only syntax. (If the author of the linked draft actually bothered to do any search they would have stumbled upon [-1], which is one of the “recent” activities).

And indeed, as you said - everyone can submit an internet draft, it’s a question of writing some XML [0], and then running it through the program to convert it to the appropriate other formats [1] and uploading it to the repository [2].

From there on, however, the easy bit ends [3]: as part of the publication process before published as an RFC, the draft needs to be reviewed and approved by quite a few people with quite a few hundred years of collective experience in the field :). That’s why preparing the document within a workgroup is usually a better idea - it allows to get it into shape that will not be a waste of time for the people looking at it.

During this work, there will be a few revisions of the document, also one would often acquire coauthors which will help working on the idea and make it better.

So from my personal experience, it is between a month and several years between having an initial draft (which has been already reviewed offline and verbally thumbed up by a few people involved in the domain of expertise).

Engineers participating in IETF also have sense of humour, hence traditionally there are 1st April RFCs that are ”special”. However, amongst them are still a lot of gems of wisdom, e.g. [4]

The democratic nature of the development process makes it incredibly interesting environment to participate in, so I much recommend it.

However, the first submission at the quality of the linked one will likely cause the opposite reaction from intended, so lurking on the mailing list and/or IETF meetings and maybe finding a mentor there could be a good start.

-1. https://datatracker.ietf.org/meeting/109/materials/slides-10...

0. https://datatracker.ietf.org/doc/html/rfc7991

1. https://pypi.org/project/xml2rfc/

2. https://datatracker.ietf.org/submit/tool-instructions/

3. https://www.rfc-editor.org/pubprocess/

4. https://www.rfc-editor.org/rfc/rfc1925

This is confusing. The response to a raw Ethernet frame is JSON containing "https_response" Why drop down to a layer 1 Ethernet frame when the response is specific to HTTP?

Very interesting. Could be useful for VPNs and tunneling while masking the traffic as HTTPs. Actually has a use compared to something like IP over Avian Carriers (https://www.rfc-editor.org/rfc/rfc1149).

Do you realize that rfc1149 was a joke?

It was written on April Fools Day.

I am aware

It's essentially what zerotier does

I always assumed you had to talk your way into some committee to submit one of these. Apparently it’s wide open. But why do it? Resume padding?

It says Ethernet over HTTP, but it looks like it’s only useful for one shot request/response over TCP protocols, like HTTP 1.0.

What am I missing?

You can tunnel any protocol over any other protocol as long as the encapsulating protocol allows some kind of data payload.

This looks like a joke to me. I'd do something like encapsulating raw Ethernet frames over WebSockets, for example. Basically, something like OpenVPN does in tap mode, just standardized. And maybe with the possibility of protocol switching on the fly.

No need to reinvent the wheel.

Reply on news.ycombinator.com