Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

03 - IPSEC (Opcional vs Obrigatório)

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione 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 Protocol do cabeçalho IPv4 com valores 51 (AH) ou 50 (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.