03 - IPSEC (Opcional vs Obrigatório)
video: https://youtu.be/... no frontmatter da nota.IPsec: Opcional no IPv4 vs Obrigatório no IPv6
O suporte ao IPsec (Internet Protocol Security) é uma das diferenças mais significativas em termos de arquitetura de segurança entre o IPv4 e o IPv6. Enquanto no IPv4 a segurança na camada de rede é um recurso adicional e frequentemente complexo de implementar, no IPv6 ela é uma parte integrante e mandatória da especificação do protocolo.
Essa mudança reflete a evolução da Internet: o IPv4 foi projetado em uma era de confiança mútua (redes acadêmicas e militares da ARPANET), onde a segurança era uma preocupação secundária. O IPv6, desenvolvido a partir de 1995 para a Internet comercial e pública moderna, foi construído sob a premissa de que a rede é um ambiente hostil e que a segurança deve ser nativa, não um adendo.
1. Arquitetura Geral do IPsec
Antes de comparar IPv4 e IPv6, é preciso entender que o IPsec é um conjunto de protocolos, não um protocolo único. Ele é definido principalmente nas RFCs 4301 a 4309 e composto por:
| Componente | Função | RFC |
|---|---|---|
| AH (Authentication Header) | Integridade + autenticação da origem (sem criptografia) | RFC 4302 |
| ESP (Encapsulating Security Payload) | Confidencialidade (criptografia) + integridade + autenticação | RFC 4303 |
| IKE (Internet Key Exchange) | Negociação automática de chaves e SAs | RFC 7296 (IKEv2) |
| SPD (Security Policy Database) | Define qual tráfego deve ser protegido | RFC 4301 |
| SAD (Security Association Database) | Mantém parâmetros das SAs ativas (chaves, algoritmos, SPI) | RFC 4301 |
A Security Association (SA) é o conceito central: trata-se de um acordo unidirecional entre duas partes que define algoritmos, chaves e tempo de vida. Toda comunicação IPsec bidirecional exige no mínimo duas SAs (uma por sentido).
2. IPv4: IPsec como Extensão Opcional
No contexto do IPv4, o IPsec é definido como uma extensão opcional do protocolo. Ele não está contido no cabeçalho principal original (RFC 791), mas sim anexado através de mecanismos adicionais.
- Arquitetura "Add-on": O IPsec no IPv4 é um "acoplamento" posterior. Para utilizá-lo, os sistemas operacionais e dispositivos de rede devem implementar um conjunto separado de protocolos que funcionam "ao lado" do IP, manipulando os pacotes antes ou após o processamento padrão. O protocolo é carregado usando o campo
Protocoldo cabeçalho IPv4 com valores51(AH) ou50(ESP). - Implementação Não Universal: Por ser opcional, nem todos os dispositivos IPv4 suportam IPsec. Um roteador barato de varejo ou um sistema operacional antigo pode rotear IPv4 perfeitamente, mas ser totalmente incapaz de processar pacotes IPsec. Isso exige que implementadores verifiquem suporte explicitamente antes de estabelecer túneis.
- Barreiras com NAT: A implementação de IPsec no IPv4 é frequentemente dificultada pelo uso disseminado de NAT. Como o IPsec criptografa o cabeçalho de transporte (incluindo portas TCP/UDP) e os endereços IP originais (em modo Tunnel), ele quebra o funcionamento do NAT, que precisa dessas informações para traduzir as conexões. Isso exige técnicas complexas como NAT-T (NAT Traversal) — RFC 3947/3948 — que encapsula pacotes ESP em UDP porta 4500 para atravessem dispositivos NAT.
3. IPv6: IPsec Nativo (Obrigatório)
No IPv6, o suporte ao IPsec é um requisito mandatório da especificação original (RFC 2460, agora RFC 8200). Isso significa que qualquer nó compatível com a especificação completa do IPv6 deve ser capaz de processar cabeçalhos IPsec.
- Integração via Cabeçalhos de Extensão: O IPv6 foi desenhado com um mecanismo flexível de "Cabeçalhos de Extensão" (Extension Headers). O IPsec não é um protocolo externo, mas utiliza dois cabeçalhos específicos:
- AH (Authentication Header, Next Header = 51): Fornece integridade de dados e autenticação da origem (garante quem enviou e que o dado não foi alterado), mas não criptografa o conteúdo.
- ESP (Encapsulating Security Payload, Next Header = 50): Fornece confidencialidade (criptografia) do payload, além de autenticação e integridade.
- Cabeçalho "Next Header": O fluxo de processamento no IPv6 permite que o IPsec seja inserido naturalmente na cadeia de cabeçalhos. O cabeçalho IPv6 aponta para o cabeçalho AH ou ESP, que por sua vez aponta para o cabeçalho da Camada de Transporte (TCP/UDP) ou para o próximo cabeçalho de extensão.
- IKE (Internet Key Exchange): O suporte obrigatório também se estende à infraestrutura de gerenciamento de chaves. O IPv6 exige suporte ao IKEv2 para a negociação automatizada de chaves criptográficas, facilitando a criação de VPNs e túneis seguros sem configuração manual complexa.
Importante: Obrigatório é a Capacidade, não o Uso
Embora o IPsec seja obrigatório na especificação do IPv6, isso não significa que todo tráfego IPv6 é criptografado automaticamente. O que é obrigatório é a capacidade de processá-lo. Em 2011, a RFC 6434 flexibilizou o requisito de implementação para "SHOULD" (recomendado) ao invés de "MUST" (obrigatório), mas na prática todos os sistemas operacionais modernos (Linux, Windows, macOS, BSD) ainda implementam IPsec nativamente em suas pilhas IPv6.
4. Modos de Operação: Transporte vs Túnel
Independentemente da versão do IP, o IPsec opera em dois modos principais:
| Modo | Escopo da Proteção | Uso Típico |
|---|---|---|
| Transporte | Apenas payload (cabeçalho IP original é preservado) | Comunicação host-a-host (cliente-servidor) |
| Túnel | Pacote IP inteiro é encapsulado em novo cabeçalho IP | VPN site-to-site, remote access |
No modo Transporte, o cabeçalho AH/ESP é inserido entre o cabeçalho IP e o cabeçalho TCP/UDP. No modo Túnel, o pacote IP original completo (com seu cabeçalho) é criptografado e encapsulado dentro de um novo pacote IP, com novos endereços de origem e destino (geralmente os gateways VPN).
5. Algoritmos Criptográficos Suportados
O IPsec moderno (definido pelo IETF) suporta uma variedade de algoritmos classificados em três categorias:
- Criptografia (Confidencialidade): AES-CBC (RFC 3602), AES-GCM (RFC 4106, recomendado), AES-CCM (RFC 4309), ChaCha20-Poly1305 (RFC 7634, preferido em dispositivos móveis), 3DES (obsoleto, RFC 2451), DES (proibido).
- Integridade (Autenticação): HMAC-SHA-256/384/512 (RFC 4868), AES-GMAC (RFC 4543), HMAC-MD5 (obsoleto, RFC 2403).
- IKE (Diffie-Hellman): Groups 14 (2048 bits, mínimo), 15, 16, 17, 18 (MODP), 19/20/21 (ECDH sobre Curve25519, P-256, P-384 — RFC 8031), 31 (Curve448).
6. Impacto na Arquitetura de Segurança
A distinção entre opcional e obrigatório muda o paradigma de como a segurança é pensada na rede.
A. Fim-a-Fim vs Hop-a-Hop
Como o IPv6 elimina a necessidade de NAT (em cenários ideais, com endereços globais únicos), o modelo IPsec nativo permite que a segurança seja verdadeiramente fim-a-fim (End-to-End).
- No IPv4, a segurança muitas vezes termina no firewall/roteador da borda (onde o NAT ocorre) e é reiniciada internamente, criando pontos de vulnerabilidade.
- No IPv6, um pacote pode ser criptografado pelo host de origem e descriptografado apenas pelo host de destino, garantindo que nem mesmo os roteadores intermediários consigam inspecionar o conteúdo dos dados.
B. Visão e Facilidade de Uso
Isso cria um ambiente onde configurar uma VPN ou comunicação segura entre dois nós IPv6 é tecnicamente mais fácil e padronizado, pois os desenvolvedores podem contar com a presença das bibliotecas criptográficas necessárias em qualquer dispositivo compatível.
7. Comparação com Outras Soluções de VPN
O IPsec não é a única opção para comunicação segura. Vale contextualizá-lo:
| Solução | Camada OSI | Vantagens | Desvantagens |
|---|---|---|---|
| IPsec | Camada 3 (Rede) | Padrão IETF, transparente para aplicação, performance hardware | Configuração complexa, problemas com NAT |
| TLS/SSL | Camada 7 (Aplicação) | Simples, ubíquo, atravessa NAT | Por aplicação, não protege outros protocolos |
| OpenVPN | Camada 3 (sobre TLS) | Atravessa NAT fácil, multiplataforma | Overhead de TCP/UDP, mais lento que IPsec |
| WireGuard | Camada 3 (UDP custom) | Código enxuto (4.000 linhas), rápido, moderno | Protocolo novo, menos auditado |
8. Exemplo Prático: Configuração no Linux (strongSwan)
# /etc/ipsec.conf - VPN site-to-site IPv6
conn site-a-to-site-b
authby=secret
auto=start
keyexchange=ikev2
ike=aes256gcm16-prfsha384-ecp384!
esp=aes256gcm16-ecp384!
left=2001:db8:1::1
leftsubnet=2001:db8:a::/64
right=2001:db8:2::1
rightsubnet=2001:db8:b::/64
Após configurar, deve-se verificar SAs ativas:
ip xfrm state # Mostra SAs (Security Associations)
ip xfrm policy # Mostra políticas SPD
ip -6 xfrm state ls # Lista SAs IPv6 ativas
9. Resumo Comparativo
| Característica | IPv4 (Opcional) | IPv6 (Obrigatório) |
|---|---|---|
| Status na Especificação | Extensão (RFC 2401+) | Parte da especificação principal (RFC 4301+, RFC 8200) |
| Integração | Camada separada ou módulo | Integrado via Cabeçalhos de Extensão |
| Disponibilidade | Dependente do fornecedor/OS | Garantida em nós compatíveis |
| Relação com NAT | Conflita (requer NAT-T) | Projetado para operar sem NAT |
| Transporte IPsec | Via campo Protocol (50/51) | Via Next Header (50/51) |
| Objetivo principal | VPNs e túneis específicos | Segurança nativa para qualquer fluxo |
10. Conclusão
Em suma, enquanto o IPv4 trata a segurança como um "apêndice" aplicado quando necessário, o IPv6 a trata como um "órgão" vital do sistema de comunicação, assegurando que a infraestrutura básica da internet esteja pronta para criptografia e autenticação nativas em escala global. Na prática, no entanto, IPsec ainda é predominantemente usado em VPNs site-to-site corporativas (IPv4 ou IPv6), enquanto a maior parte do tráfego seguro na internet hoje é protegida por TLS na Camada de Aplicação. A obrigatoriedade do IPsec no IPv6 garante que, quando necessário, a infraestrutura está preparada — não que todo fluxo seja criptografado por padrão.