Uma proposta inesperada dentro do IETF – Ethernet sobre HTTPS
03/04/2024
Por Alejandro Acosta – Coordenador de Pesquisa e Desenvolvimento do LACNIC
Neste post eu quero falar principalmente sobre um documento com pouco tempo no IETF chamado “Ethernet sobre HTTPS”. Devo confessar que esse nome chamou minha atenção.
História
A necessidade de encapsular um protocolo em outro não é novidade. De fato, esta prática já tem cerca de 30 anos.
Voltemos aos anos 90. Nesses anos aconteceu de tudo em termos da ideia de encapsular um protocolo em outro. Por exemplo, IP-IP (IP em IP) surgiu quando a Internet estava nas suas fases iniciais de expansão comercial e procuravam-se formas de conectar redes privadas sobre a infraestrutura de rede pública, o que hoje conhecemos como Internet.
Nessa mesma década, sem ir muito longe, surgiram outras tecnologias que ainda são muito populares como -o querido- GRE, PPTP, L2TP; e mesmo no final dos anos 90 e início dos anos 2000, houve grandes avanços com VPNs IPSEC.
Mas não avancemos tão longe no tempo, vamos ficar mais um pouco nos anos 90. Eles não apenas queriam encapsular o IPv4 no IPv4, mas também deram um passo à frente com o IPv6 e em 1998 apareceu o protocolo 41 (IPv6 no IPv4).
A partir daqui, o resto é história. Já foram feitas inúmeras “misturas” de encapsulamentos de protocolos, como o IPv4 sobre IPv6, IPv6 sobre UDP sobre IPv4, Ethernet sobre IP e um longo etecetera.
Ok, voltemos ao draft Ethernet sobre HTTPS
No final de 2023, especificamente no dia 27 de dezembro, no âmbito do Grupo de Trabalho INTAREA (Internet Area Working Group), chegou um draft com o título Ethernet sobre HTTPS,
O draft trata de quê?
O draft busca definir um protocolo para encapsular tramas Ethernet sobre HTTPS, permitindo uma comunicação segura entre clientes e servidores web internos.
Como se pretende alcançar o acima exposto?
Na seção 1.2 do documento é feita a seguinte explicação, que podemos resumir da seguinte forma:
O cliente, ao especificar uma URL interna, reconhece que deve ser usado Ethernet sobre HTTPS para a comunicação. O navegador do cliente, pré-configurado com o endereço IP e a porta do servidor HTTP atuando como gateway para a LAN, inicia o protocolo Ethernet sobre HTTPS e envia um pedido de autenticação ao servidor. Uma vez autenticado, o cliente envia um pedido de página web interna encapsulada em um pedido HTTPS. O servidor descapsula a trama Ethernet, extrai o pedido HTTP original e o encaminha para o servidor web interno. O servidor então encapsula a resposta do servidor web interno e a envia de volta ao cliente.
Diagrama de operação
+----------------------+ +----------------------+
| | | |
| Web Client | | EOH Server |
| | | |
+----------------------+ +----------------------+
| |
| 1. Browser Recognizes |
| Internal URL |
| --------------------------> |
| |
| 2. Authentication Request |
| --------------------------> |
| |
| |
| 3. Browser Initiates |
| Ethernet over HTTPS |
| |
| |
| 4. Server Authenticates |
| and Responds |
| <-------------------------- |
| |
| 5. Internal Webpage Request |
| as Encapsulated Frame |
| --------------------------> |
| |
| 6. Server Decapsulation |
| and Routing |
| <-------------------------- |
| |
| 7. Response to Client |
| as Encapsulated Frame |
| --------------------------> |
| |Resposta ao cliente
O draft explica que a resposta a um pedido de um cliente é no formato JSON. Um exemplo seria:
POST /ethernet-over-https HTTP/1.1
Host: server.example.com
Content-Type: application/octet-stream
Content-Length: length_of_payload_in_bytes
{
"http_response": "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<html>Internal Webpage</html>"
}Pontos positivos do draft
- Trata de um tema interessante, pode ser novo e ter um grande número de implementações.
- No momento é um draft curto e enfatiza corretamente a área de segurança e autenticação.
Dúvidas que deixa o draft
- O problema não fica bem definido, é difícil entender porque quer se resolver uma situação no nível HTTP desde Ethernet.
- Pareceria que o servidor EoH é semelhante a um proxy
- A área de segurança no nível da camada 2 é muito delicada, deveria pelo menos ser mencionada no draft
- Expressam respostas em json de mac_address e endereços IP com um exemplo do IPv4 ☹️
- Inquestionavelmente, a explicação de como funciona deixa muitas dúvidas
- É muito normal no mundo do encapsulamento ter preocupações na área de excesso de payload. Transportar Ethernet sobre HTTPS é literalmente carregar todo o modelo TCP/IP em HTTPS
- Ao ponto anterior devemos acrescentar os possíveis problemas de MTU que este tipo de soluções pode acarretar.
- Já existem vários trabalhos nesse sentido, o primeiro é o draft “Proxying Ethernet in HTTP” e um software que faz justamente o que o draft promete chamado Softether. O acima sem mencionar “Proxying IP in HTTP”, que já é um RFC Standard Track (RFC 9484).
Previsão sobre o draft
Relembrando o funcionamento do IETF (ver diagrama abaixo), em que os indivíduos propõem drafts de forma pessoal, depois são adotados pelo WG e, posteriormente, após consenso da comunidade em várias etapas, são adotados como RFC.
O Processo de Publicação do IETF
Com a versão atual, não parece que o draft avance muito. Eu acho que vai ficar longe do consenso dentro do IETF. Hoje não há maior apoio da comunidade, porém não quero descartá-lo 100% porque podem acontecer coisas que deem uma reviravolta, como conseguir novos autores, conseguir um “running code”, apresentá-lo pessoalmente e muitas outras coisas.
Conclusões
É um draft que propõe uma ideia arriscada, digamos reflexiva, sem um problema claro para resolver. Este é um exemplo claro de que nem todos os documentos que chegam ao IETF são tão elaborados, às vezes são apenas ideias para medir a temperatura da comunidade.
O que você acha deste draft? Você tem coragem de enviar algum documento ao IETF?