Entender o protocolo IPsec IKEv1

Introduction

Este documento descreve o processo de protocolo do Internet Key Exchange (IKEv1) para o estabelecimento de uma Rede Virtual Privada (VPN - Virtual Private Network) para entender a troca de pacotes para uma solução de problemas mais simples para qualquer tipo de problema de Internet Protocol Security (IPsec - Internet Protocol Security) com IKEv1.

Contribuído por Amanda Nava, engenheira do TAC da Cisco.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento dos conceitos básicos de segurança:

• Autenticação
• Confidencialidade
• Integridade
• IPsec

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando

IPsec

O IPsec é um conjunto de protocolos que fornece segurança às comunicações pela Internet na camada IP. O uso atual mais comum do IPsec é fornecer uma Rede Virtual Privada (VPN - Virtual Private Network), entre dois locais (gateway para gateway) ou entre um usuário remoto e uma rede corporativa (host para gateway).

Protocolo IKE

O IPsec usa o protocolo IKE para negociar e estabelecer túneis de VPN (Virtual Private Network, rede virtual privada) de acesso remoto ou site a site protegidos. O protocolo IKE também é chamado de Internet Security Association and Key Management Protocol (ISAKMP) (somente na Cisco).

Há duas versões de IKE:

• IKEv1: Definido no RFC 2409, o Internet Key Exchange
• IKE versão 2 (IKEv2): Definido no RFC 4306, Protocolo de Intercâmbio de Chave de Internet (IKEv2)

Fases IKE

O ISAKMP separa a negociação em duas fases:

• Fase 1: Os dois pares ISAKMP estabelecem um túnel seguro e autenticado, que protege as mensagens de negociação ISAKMP. Esse túnel é conhecido como ISAKMP SA. Há dois modos definidos pelo ISAKMP: Modo principal (MM) e Modo agressivo.
• Fase 2: Ele negocia os principais materiais e algoritmos para a criptografia (SAs) dos dados a serem transferidos pelo túnel IPsec. Essa fase é chamada de Modo rápido.

Para materializar todos os conceitos abstratos, o túnel da Fase 1 é o túnel pai e a fase 2 é um subtúnel, essa imagem ilustra as duas fases como túneis.

Note: O túnel da fase 1 (ISAKMP) protege o tráfego VPN do plano de controle entre os dois gateways. O tráfego do plano de controle pode ser Pacotes de negociação, pacotes de informações, DPD, keepalives, rekey, etc. A negociação de ISAKMP usa as portas UDP 500 e 4500 para estabelecer um canal seguro.

Note: O túnel de fase 2 (IPsec) protege o tráfego do plano de dados que passa pela VPN entre os dois gateways. TOs algoritmos usados para proteger os dados são configurados na Fase 2 e independentes dos especificados na Fase 1.
O protocolo usado para encapsular e criptografar esses pacotes é o ESP (Encapsulation Security Payload, payload de segurança de encapsulamento).

Modos IKE (Fase 1)

Modo principal

Uma sessão IKE começa quando o iniciador envia uma proposta ou proposta ao respondente. A primeira troca entre nós estabelece a política de segurança básica; o iniciador propõe os algoritmos de criptografia e autenticação a serem usados. O respondente escolhe a proposta apropriada (presumiremos que uma proposta seja escolhida) e a envia ao iniciador. A próxima troca passa por chaves públicas Diffie-Hellman e outros dados. Todas as outras negociações são criptografadas no SA IKE. A terceira troca autentica a sessão ISAKMP. Depois que a SA IKE é estabelecida, a negociação de IPSec (modo rápido) é iniciada.

Modo agressivo

O Modo Agressivo compacta a negociação SA de IKE em três pacotes, com todos os dados necessários para a SA passados pelo iniciador. O respondente envia a proposta, o material principal e a ID e autentica a sessão no próximo pacote. O iniciador responde e autentica a sessão. A negociação é mais rápida, e o iniciador e a ID do respondedor passam para a frente.

Modo IPsec (Fase 2)

Modo rápido

A negociação de IPSec, ou Modo Rápido, é semelhante a uma negociação de IKE de Modo Agressivo, exceto a negociação, que deve ser protegida em um SA IKE. O modo rápido negocia o SA para a criptografia de dados e gerencia a troca de chaves para esse IPSec SA.

Glossário IKE

• Uma associação de segurança (SA) é o estabelecimento de atributos de segurança compartilhados entre duas entidades de rede para dar suporte à comunicação segura. Um SA inclui atributos como algoritmo criptográfico e modo; chave de encriptação de tráfego; e parâmetros para que os dados da rede passem pela conexão.
• As IDs de fornecedor (VID) são processadas para determinar se o peer suporta o recurso NAT-Traversal, Dead Peer Detection, Fragmentation etc.
• Nonce: um número gerado aleatoriamente que o iniciador envia. Esse nonce é hash juntamente com os outros itens com a chave acordada usada e é enviado de volta. O iniciador verifica o cookie e o "nonce" e rejeita todas as mensagens que não têm o "nonce" correto. Isso ajuda a evitar a repetição, já que nenhum terceiro pode prever o que é o nonce gerado aleatoriamente.
• Informações de troca de chaves (KE) para o processo seguro de troca de chaves Diffie-Hellman (DH).
• O Identity Initiator/responder (IDi/IDr.) é usado para enviar informações de autenticação ao peer. Estas informações são transmitidas sob a proteção do segredo comum partilhado.
• A troca de chaves Diffie-Hellman (DH) é um método de troca segura de algoritmos criptográficos em um canal público.
  
• A chave compartilhada IPSec pode ser derivada com o DH usado novamente para garantir o Perfect Forward Secret (PFS) ou a troca DH original atualizada para o segredo compartilhado derivado anteriormente.

Troca de pacotes no modo principal

Cada pacote ISAKMP contém informações de payload para o estabelecimento do túnel. O glossário IKE explica as abreviações IKE como parte do conteúdo da carga útil para a troca de pacotes no modo principal, como mostrado nesta imagem.

Modo principal 1 (MM1)

Para definir os termos das negociações ISAKMP, você cria uma política ISAKMP, que inclui:

• Um método de autenticação, para garantir a identidade dos peers.
• Um método de criptografia para proteger os dados e garantir a privacidade.
• Um método HMAC (Hash Message Authentication Codes, Códigos de autenticação de mensagem com hash) para garantir a identidade do remetente e para garantir que a mensagem não tenha sido modificada em trânsito.
• Um grupo Diffie-Hellman para determinar a força do algoritmo de determinação da chave de criptografia. O Security Appliance usa esse algoritmo para derivar as chaves de criptografia e hash.
• Limite de tempo que o Security Appliance usa uma chave de criptografia antes de ser substituída.

O primeiro pacote é enviado pelo iniciador da negociação IKE, como mostrado na imagem.

 

Note: O modo principal 1 é o primeiro pacote da negociação IKE. Portanto, o SPI do iniciador é definido como um valor aleatório enquanto o SPI do respondedor é definido como 0.  No segundo pacote (MM2), o SPI do respondedor deve ser respondido com um novo valor e toda a negociação mantém os mesmos valores de SPIs.

Se o MM1 for capturado e um analisador de protocolo de rede Wireshark for usado, o valor do SPI estará dentro do conteúdo do Internet Security Association and Key Management Protocol , como mostrado na imagem.

Note: No caso, o pacote MM1 é perdido no caminho ou não há resposta de MM2, a negociação de IKE mantém as retransmissões de MM1 até que o número máximo de retransmissões seja atingido. Neste ponto, o Iniciador mantém o mesmo SPI até que a próxima negociação seja acionada novamente.

Tip: A identificação dos SPIs do iniciador e do respondedor é muito útil para identificar várias negociações para a mesma VPN e restringir alguns problemas de negociação.

Identificar duas negociações simultâneas

Nas plataformas Cisco IOS® XE, as depurações podem ser filtradas por túnel com uma condição para o endereço IP remoto configurado, no entanto, as negociações simultâneas são exibidas nos registros e não há como filtrá-los. É necessário fazê-lo manualmente. Como mencionado anteriormente, toda a negociação mantém os mesmos valores de SPI para iniciador e respondente. Caso um pacote seja recebido do mesmo endereço IP do peer, mas o SPI não corresponda ao valor anterior rastreado antes que a negociação atinja o número máximo de retransmissão, é outra negociação para o mesmo peer como mostrado na imagem.

Note: O exemplo mostra a negociação simultânea para o primeiro pacote na negociação (MM1), no entanto, isso pode ocorrer em qualquer ponto de negociação. Todos os pacotes subsequentes devem incluir um valor diferente de 0 no SPI do respondente.

Modo principal 2 (MM2)

No pacote Main Mode 2, o respondente envia a política selecionada para as propostas correspondentes, e o SPI do respondente é definido como um valor aleatório. Toda a negociação mantém os mesmos valores de SPIs. O MM2 responde a MM1 e o respondedor SPI é definido com um valor diferente de 0, como mostrado na imagem.

Se o MM2 for capturado e um analisador de protocolo de rede Wireshark for usado, os valores SPI do iniciador e SPI do respondedor estarão dentro do conteúdo da Associação de segurança da Internet e do Protocolo de gerenciamento de chaves, como mostrado na imagem.

Modo principal 3 e 4 (MM3-MM4)

Os pacotes MM3 e MM4 ainda são descriptografados e não autenticados e a troca de chaves secretas ocorre. MM3 e MM4 são mostrados na imagem.

Modo principal 5 e 6 (MM5-MM6)

Os pacotes MM5 e MM6 já estão criptografados, mas ainda não foram autenticados. Nesses pacotes, a autenticação ocorre conforme mostrado na imagem.

Modo rápido (QM1, QM2 e QM3)

O modo rápido ocorre após o monde principal e o IKE estabeleceu o túnel seguro na fase 1. O modo rápido negocia a política de IPSec compartilhada para os algoritmos de segurança de IPSec e gerencia a troca de chaves para o estabelecimento de SA de IPSec. Os nonces são usados para gerar um novo material de chave secreta compartilhada e impedir ataques de repetição de SAs falsos gerados.

Três pacotes são trocados nesta fase, como mostrado na imagem.

Troca de pacotes de modo agressivo

 O modo agressivo pressiona a negociação SA de IKE em três pacotes, com todos os dados necessários para a SA passados pelo iniciador.

• O respondente envia a proposta, o material principal e a ID e autentica a sessão no próximo pacote.
• O iniciador responde e autentica a sessão.
• A negociação é mais rápida, e o iniciador e a ID do respondedor passam para a frente.

A imagem mostra o conteúdo da carga útil dos três pacotes trocados no modo Agressivo.

Modo principal vs Modo agressivo

Comparado ao modo principal, o modo agressivo desce para três pacotes:

• AM 1 absorve MM1 e MM3
• A AM 2 absorve MM2, MM4 e parte da MM6. É daí que vem a vulnerabilidade do modo agressivo. O AM 2 compõe o IDr e a Autenticação não criptografados, ao contrário do Modo principal, essas informações são criptografadas.
• O AM 3 fornece a IDi e a Autenticação; esses valores são criptografados.

IKEv2 versus troca de pacotes IKEv1

Na negociação de IKEv2, menos mensagens são trocadas para estabelecer um túnel. O IKEv2 usa quatro mensagens; O IKEv1 usa seis mensagens (no modo principal) ou três mensagens (no modo agressivo).

Os tipos de mensagem IKEv2 são definidos como pares de Solicitação e Resposta. A imagem mostra a comparação de pacotes e o conteúdo de payload de IKEv2 versus IKEv1.

Note: Este documento não descreve mais profundamente a troca de pacotes IKEv2. Para obter mais referências, navegue até IKEv2 Packet Exchange e Protocol Level Debugging.

Baseado em políticas versus baseado em rotas

VPN baseada em políticas

Como o nome indica, uma VPN baseada em políticas é um túnel VPN IPsec com uma ação de política para o tráfego de trânsito que atende aos critérios de correspondência da política. No caso de dispositivos Cisco, uma lista de acesso (ACL) é configurada e anexada a um mapa de criptografia para especificar o tráfego a ser redirecionado para a VPN e criptografado.

Os seletores de tráfego são as sub-redes ou os hosts especificados na política, como mostrado na imagem.

VPN baseada em rota

Uma política não é necessária e o tráfego é redirecionado para os túneis com rotas e suporta o roteamento dinâmico pela interface do túnel. Os seletores de tráfego (tráfego criptografado através da VPN) são de 0.0.0.0. para 0.0.0.0 por padrão, como mostrado na imagem.

Note: Devido ao fato dos seletores de tráfego serem 0.0.0.0, qualquer host ou sub-rede está incluído, portanto, somente um SA é criado. Há uma exceção para o túnel dinâmico. Este documento não descreve túneis dinâmicos.

A VPN baseada em política e rota pode ser materializada como mostrado na imagem.

.

Note: Diferentemente da VPN baseada em rota com apenas uma SA criada, a VPN baseada em política pode criar vários SAs. À medida que uma ACL é configurada, cada instrução na ACL (se for diferente entre elas) cria um subtúnel.

Problemas comuns de tráfego não recebem através da VPN

ISP bloqueia UDP 500/4500

É muito comum que o ISP (Internet Services Provider, Provedor de Serviços de Internet) bloqueie as portas UDP 500/4500. Para um estabelecimento de túnel IPsec, dois ISPs diferentes podem ser envolvidos e um deles pode bloquear as portas e o outro permite.

A imagem mostra os dois cenários em que um ISP pode bloquear as portas UDP 500/4500 em apenas uma direção.

Note: A porta UDP 500 é usada pelo Internet Key Exchange (IKE) para o estabelecimento de túneis VPN seguros. O UDP 4500 é usado quando o NAT está presente em um ponto de extremidade de VPN.

Note: Quando o ISP bloqueia o UDP 500/4500, o estabelecimento do túnel IPsec é afetado e não se ativa.

ISP bloqueia ESP

Outro problema muito comum em túneis IPsec é que o ISP bloqueia o tráfego ESP, no entanto, ele permite as portas UDP 500/4500. Por exemplo, as portas UDP 500/4500 são permitidas de forma bidirecional, portanto, o túnel é estabelecido com êxito, mas os pacotes ESP são bloqueados pelo ISP ou ISPs em ambas as direções, o que faz com que o tráfego criptografado através da VPN falhe, como mostrado na imagem.

Note: Quando o ISP bloqueia pacotes ESP, o estabelecimento do túnel IPsec é bem-sucedido, mas o tráfego criptografado é afetado. Que pode ser refletido com a VPN ativada, mas o tráfego não funciona sobre ela. 

Tip: O cenário em que o tráfego ESP é bloqueado somente em uma direção também pode estar presente, os sintomas são os mesmos, mas pode ser facilmente encontrado com as informações de estatísticas de túnel, encapsulamento, contadores de desencapsulamento ou contadores RX e TX.

Informações Relacionadas

• Intercâmbio de pacote KEv2 e depuração de nível de protocolo
• O Internet Key Exchange (IKE) - RFC 2409
• Protocolo IKEv2 (Internet Key Exchange)
• Suporte Técnico e Documentação - Cisco Systems