Internet Key Exchange (IKE) para VPN IPsec

Processamento de pacotes IKE

Quando um pacote cleartext chega em um dispositivo da Juniper Networks que requer tunelamento, e nenhuma SA de Fase 2 ativa existe para esse túnel, o Junos OS inicia negociações de IKE e derruba o pacote. Os endereços de origem e destino no cabeçalho de pacotes IP são os dos gateways IKE locais e remotos, respectivamente. Na carga de pacotes IP, há um segmento UDP encapsulando um pacote ISAKMP (IKE). O formato para pacotes IKE é o mesmo para a Fase 1 e a Fase 2. Veja Figura 1.

Enquanto isso, o host de origem enviou o pacote descartado novamente. Normalmente, quando o segundo pacote chega, as negociações de IKE estão concluídas, e o Junos OS protege o pacote e todos os pacotes subsequentes na sessão — com O IPsec antes de encaminhá-lo.

Figura 1: Pacote IKE para fases 1 e 2

O campo Next Payload contém um número que indica um dos seguintes tipos de carga útil:

• 0002 — O SA Negotiation Payload contém uma definição para uma SA Fase 1 ou Fase 2.

• 0004 — A carga útil da proposta pode ser uma proposta de Fase 1 ou Fase 2.

• 0008 — Transform Payload é encapsulado em uma proposta de carga que é encapsulada em uma carga SA.

• 0010 — A carga útil do Key Exchange (KE) contém informações necessárias para a realização de uma troca chave, como um valor público de DH.

• 0020 — Identificação (IDx) Carga útil.

  • Na Fase 1, a IDii indica o ID do iniciador, e o IDir indica o ID do respondente.

  • Na Fase 2, a IDui indica o iniciador do usuário, e a IDur indica o respondente do usuário.

  Os IDs são tipos de ID IKE, como FQDN, U-FQDN, endereço IP e ASN.1_DN.

• 0040 — Carga útil do certificado (CERT).

• 0080 — Carga útil de solicitação de certificado (CERT_REQ).

• 0100 — Hash (HASH) Payload contém a saída de digestão de uma determinada função hash.

• 0200 — O Payload de assinatura (SIG) contém uma assinatura digital.

• 0400 — Nonce (Nx) Payload contém algumas informações pseudorandom necessárias para a troca.

• 0800 — Notifique a carga.

• 1000 — ISAKMP Delete Payload.

• 2000 — A carga útil de ID (VID) do fornecedor pode ser incluída em qualquer lugar nas negociações da Fase 1. O Junos OS o usa para marcar o suporte para o NAT-T.

Cada carga ISAKMP começa com o mesmo cabeçalho genérico, como mostrado em Figura 2.

Figura 2: Cabeçalho genérico de carga de ISAKMP

Pode haver várias cargas ISAKMP acorrentadas em conjunto, com cada tipo de carga subsequente indicado pelo valor no campo Next Header. Um valor indica 0000 a última carga ISAKMP. Veja Figura 3 um exemplo.

Figura 3: Cabeçalho ISAKMP com cargas ISAKMP genéricas

Processamento de pacotes IPsec

Após a conclusão das negociações do IKE e dos dois gateways IKE terem estabelecido as associações de segurança de Fase 1 e Fase 2 (SAs), todos os pacotes subsequentes são encaminhados usando o túnel. Se a SA da Fase 2 especificar o Protocolo de Segurança de Encapsulamento (ESP) no modo túnel, o pacote se parece com o mostrado em Figura 4. O dispositivo adiciona dois cabeçalhos adicionais ao pacote original que o host de iniciação envia.

Como mostrado, Figura 4o pacote que o host de iniciação constrói inclui a carga, o cabeçalho TCP e o cabeçalho IP interno (IP1).

Figura 4: Pacote IPsec — ESP no modo túnel

O cabeçalho IP do roteador (IP2), que o Junos OS adiciona, contém o endereço IP do gateway remoto como endereço IP de destino e o endereço IP do roteador local como endereço IP de origem. O Junos OS também adiciona um cabeçalho ESP entre os cabeçalhos IP externos e internos. O cabeçalho ESP contém informações que permitem ao peer remoto processar adequadamente o pacote quando ele o recebe. Isso é mostrado em Figura 5.

Figura 5: Cabeçalho IP externo (IP2) e cabeçalho ESP

O campo Next Header indica o tipo de dados no campo de carga. No modo túnel, esse valor é 4, indicando que um pacote IP está contido dentro da carga. Veja Figura 6.

Figura 6: Cabeçalho IP interno (IP1) e cabeçalho TCP

Configuração do IKEv2 no Junos OS

Um peer VPN está configurado como IKEv1 ou IKEv2. Quando um peer é configurado como IKEv2, ele não pode voltar ao IKEv1 se seu peer remoto iniciar a negociação IKEv1. Por padrão, os dispositivos de segurança da Juniper Networks são pares IKEv1.

Use a version v2-only declaração de configuração no nível [edit security ike gateway gw-name] de hierarquia para configurar o IKEv2.

A versão IKE é exibida na saída dos comandos operacionais da CLI e show security ipsec security-associations da show security ike security-associations CLI.

Os dispositivos da Juniper Networks oferecem suporte a até quatro propostas para negociações da Fase 2, permitindo que você defina o quão restritivos uma gama de parâmetros de túnel você aceitará. O Junos OS fornece conjuntos de propostas de Fase 2 predefinidos, compatíveis e básicos. Você também pode definir propostas personalizadas da Fase 2.

Entendendo a carga de configuração do IKEv2

A carga de configuração é uma opção de Internet Key Exchange versão 2 (IKEv2) oferecida para propagar informações de provisionamento de um respondente a um iniciador. A carga de configuração IKEv2 é suportada apenas com VPNs baseadas em rota.

RFC 5996, Internet Key Exchange Protocol Versão 2 (IKEv2), define 15 atributos de configuração diferentes que podem ser devolvidos ao iniciador pelo respondente. Tabela 1 descreve os atributos de configuração IKEv2 suportados em firewalls da Série SRX.

Para que o respondente IKE forneça ao iniciador informações de provisionamento, ele deve obter as informações de uma fonte especificada, como um servidor RADIUS. As informações de provisionamento também podem ser devolvidas de um servidor DHCP por meio de um servidor RADIUS. No servidor RADIUS, as informações do usuário não devem incluir uma senha de autenticação. O perfil do servidor RADIUS está vinculado ao gateway IKE usando a aaa access-profile profile-name configuração no nível [edit security ike gateway gateway-name] de hierarquia.

A partir do Junos OS Release 20.3R1, em SRX5000 linha com o SPC3 e o firewall virtual vSRX em execução iked, melhoramos a carga de configuração do IKEv2 para:

• Suporte para o pool de endereços local IPv4 e IPv6. Você também pode atribuir um endereço IP fixo a um peer.

  Durante a criação do IKE, o iniciador solicita um endereço IPv4, endereço IPv6, endereço DNS ou endereço WINS do respondente. Após o respondente autenticar o iniciador com sucesso, ele atribui um endereço IP a partir de um pool de endereços local ou através do servidor RADIUS. Dependendo da configuração, esse endereço IP é atribuído dinamicamente cada vez quando um peer se conecta ou é atribuído como endereço IP fixo. Se o servidor RADIUS responder com um pool emoldurado, o Junos OS atribui um endereço IP ou informações com base na configuração do pool local correspondente. Se você configurar o pool de endereços local e o servidor RADIUS, o endereço IP alocado no servidor RADIUS tem precedência sobre o pool local. Se você configurar o pool local de endereços IP e o servidor RADIUS não retornarem nenhum endereço IP, o pool local atribui o endereço IP à solicitação.

• Opção adicional, none introduzida para authentication-order. Veja a ordem de autenticação (Perfil de acesso).

• As mensagens de início e parada de contabilidade RADIUS informam o estado do túnel ou peer para o servidor RADIUS. Essas mensagens podem ser usadas para rastrear finalidades ou notificações para subsistemas, como um servidor DHCP.

  Certifique-se de que a contabilidade de suporte do servidor RADIUS inicie ou interrompe as mensagens. Certifique-se também de que os firewalls da Série SRX e o servidor RADIUS tenham configurações apropriadas para rastrear essas mensagens.

• A introdução do suporte IPv6 permite túneis de pilha dupla usando a carga de configuração. Durante o processo de login, solicitações de IKE para endereços IPv4 e IPv6. A AAA só permite o login se todos os endereços solicitados tiverem sido alocados com sucesso. A IKE encerra a negociação se o IP solicitado não for alocado.

Em uma VPN baseada em rota, as interfaces de túnel seguro (st0) operam no modo ponto a multiponto ou ponto a ponto. A atribuição de endereços por meio da carga de configuração IKEv2 agora é suportada para modo ponto a ponto ou ponto a ponto. Para interfaces de ponto a multiponto, as interfaces devem ser numeradas e os endereços no tipo de carga de configuração INTERNAL_IP4_ADDRESS atributo devem estar dentro da faixa de sub-rede da interface ponto a multiponto associada.

A partir do Junos OS Release 20.1R1, você pode configurar uma senha comum para solicitações de carga de configuração IKEv2 para uma configuração de gateway IKE. A senha comum na faixa de 1 a 128 caracteres permite que o administrador defina uma senha comum. Essa senha é usada entre o firewall da Série SRX e o servidor RADIUS quando o firewall da Série SRX solicita um endereço IP em nome de um peer IPsec remoto usando a carga de configuração IKEv2. O servidor RADIUS corresponde às credenciais antes de fornecer qualquer informação de IP ao firewall da Série SRX para a solicitação de carga de configuração. Você pode configurar a senha comum usando config-payload-password configured-password a declaração de configuração no nível deedit security ike gateway gateway-name aaa access-profile access-profile-name hierarquia.

Tanto o firewall da Série SRX quanto o servidor RADIUS devem ter a mesma senha configurada e o servidor de raio deve ser configurado para usar o Protocolo de Autenticação de Senha (PAP) como o protocolo de autenticação. Sem isso, o estabelecimento de túneis não será bem sucedido.

Figura 7 mostra um fluxo de trabalho típico para uma carga de configuração IKEv2.

Figura 7: Fluxo de trabalho típico de carga de pagamento de configuração IKEv2

O recurso de carga de configuração IKEv2 é suportado tanto para interfaces de túnel seguro de ponto a multiponto (st0) quanto para interfaces ponto a ponto. As interfaces de ponto a multiponto devem ser numeradas, e os endereços fornecidos na carga de configuração devem estar dentro da faixa de sub-rede da interface ponto a multiponto associada.

A partir do Junos OS Release 20.1R1, oferecemos suporte ao recurso de carga de configuração IKEv2 com interfaces ponto a ponto na linha SRX5000 e firewall virtual vSRX em execução iked.

Entendendo o provisionamento de células pico

A carga de configuração do IKEv2 pode ser usada para propagar informações de provisionamento de um respondente IKE, como um firewall da Série SRX, para vários iniciadores, como estações base de células pico LTE em uma rede celular. As células pico são enviadas da fábrica com uma configuração padrão que lhes permite se conectar ao firewall da Série SRX, mas as informações de provisionamento de células pico são armazenadas em um ou mais servidores de provisionamento em uma rede protegida. As células pico recebem informações de provisionamento completas após estabelecer conexões seguras com os servidores de provisionamento.

O fluxo de trabalho necessário para inicializações e provisionamento de uma célula de pico e apresentá-la ao serviço inclui quatro estágios distintos:

1. Aquisição de endereços iniciais — as células pico da fábrica com as seguintes informações:

   • Configuração do túnel de gateway seguro para o firewall da Série SRX

   • Certificado digital emitido pelo fabricante

   • Nome de domínio totalmente qualificado (FQDN) dos servidores de provisionamento que estão dentro da rede protegida

   O pico cell inicializa e adquire um endereço a ser usado para negociação de IKE de um servidor DHCP. Em seguida, um túnel é construído para o gateway seguro no firewall da Série SRX usando este endereço. Um endereço para tráfego de operação, administração e gerenciamento (OAM) também é atribuído pelo servidor DHCP para uso na rede protegida.

2. Provisionamento de células Pico — Usando seu endereço de tráfego OAM atribuído, a célula pico solicita suas informações de provisionamento — tipicamente certificado do operador, licença, software e informações de configuração — de servidores dentro da rede protegida.

3. Reinicialização — a célula pico reinicia e usa as informações de provisionamento adquiridas para torná-la específica para o modelo de rede e operação do provedor de serviços.

4. Provisionamento de serviço — Quando a célula pico entra em serviço, ela usa um único certificado que contém nome distinto (DN) e valores de nome alternativos sujeitos com um FQDN para construir dois túneis para o gateway seguro no firewall da Série SRX: um para tráfego de OAM e outro para tráfego de dados do Third-Generation Partnership Project (3GPP).

Visão geral

Com o IKEv2, rekeying e reauthenticação são processos separados. A reproteção estabelece novas chaves para a associação de segurança IKE (SA) e reinicia os contadores de ID de mensagens, mas não reauthentica os pares. A reauthenticação verifica se os pares de VPN mantêm seu acesso às credenciais de autenticação. A reauthenticação estabelece novas chaves para a SA IKE e as SAs infantis; re-chaves de qualquer SA IKE pendente ou SA infantil não são mais necessários. Após a criação do novo IKE e dos SAs infantis, o antigo IKE e as SAs infantis são excluídos.

A reauthentação do IKEv2 é desativada por padrão. Você permite a reauthenticação configurando um valor de frequência de reauthentação entre 1 e 100. A frequência de reauthenticação é o número de rekeys IKE que ocorre antes que a reauthenticação ocorra. Por exemplo, se a frequência de reauthenticação configurada for 1, a reauthenticação ocorre toda vez que há uma rekey IKE. Se a frequência de reauthenticação configurada for 2, a reauthenticação ocorre em todas as outras chaves de IKE. Se a frequência de reauthenticação configurada for 3, a reauthenticação ocorre em cada terceiro IKE rekey, e assim por diante.

Você configura a frequência de reauthenticação com a reauth-frequency declaração no nível [edit security ike policy policy-name] de hierarquia. A reauthenticação é desativada configurando a frequência de reauthenticação a 0 (o padrão). A frequência de reauthenticação não é negociada por pares, e cada peer pode ter seu próprio valor de frequência de reauthenticação.

Recursos suportados

A reauthentação do IKEv2 é suportada com os seguintes recursos:

• Iniciadores ou respondentes IKEv2

• Detecção de peer morto (DPD)

• Roteadores virtuais e interfaces de túnel seguro (st0) em roteadores virtuais

• Transversal de tradução de endereços de rede (NAT-T)

• Clusters de chassi em modo ativo-ativo e passivo ativo para dispositivos de SRX5400, SRX5600 e SRX5800

• Upgrade de software em serviço (ISSU) em dispositivos de SRX5400, SRX5600 e SRX5800

• Atualize ou insira uma nova unidade de processamento de serviços (SPU) usando o procedimento de atualização de hardware em serviço (ISHU)

Limitações

Observe as seguintes advertências ao usar a reauthenticação do IKEv2:

• Com o NAT-T, um novo IKE SA pode ser criado com portas diferentes da SA IKE anterior. Nesse cenário, o antigo IKE SA pode não ser excluído.

• Em um cenário NAT-T, o iniciador por trás do dispositivo NAT pode se tornar o respondente após a reauthenticação. Se a sessão de NAT expirar, o dispositivo NAT pode descartar novos pacotes IKE que podem chegar em uma porta diferente. A manutenção de NAT-T ou DPD deve ser habilitada para manter a sessão de NAT viva. Para o AutoVPN, recomendamos que a frequência de reauthenticação configurada nos spokes seja menor do que a frequência de reauthentação configurada no hub.

• Com base na frequência de reauthenticação, uma nova SA IKE pode ser iniciada pelo iniciador ou pelo respondente do IKE SA original. Como a autenticação e a carga de configuração do Extensible Authentication Protocol (EAP) exigem que o IKE SA seja iniciado pela mesma parte que o IKE SA original, a reauthenticação não é suportada com autenticação EAP ou carga de configuração.

Hierarquia multinível para autenticação de certificados

Autenticação baseada em certificados é um método de autenticação suportado em firewalls da Série SRX durante a negociação do IKE. Em grandes redes, várias autoridades de certificado (CAs) podem emitir certificados de entidade final (EE) em seus respectivos dispositivos finais. É comum ter CAs separados para locais, departamentos ou organizações individuais.

Quando uma hierarquia de nível único para autenticação baseada em certificados é usada, todos os certificados de EE na rede devem ser assinados pelo mesmo CA. Todos os dispositivos de firewall devem ter o mesmo certificado de CA inscrito para validação de certificados de peer. A carga de certificado enviada durante a negociação do IKE contém apenas certificados EE.

Como alternativa, a carga de certificados enviada durante a negociação do IKE pode conter uma cadeia de certificados de EE e CA. Uma cadeia de certificados é a lista de certificados necessários para validar o certificado EE de um peer. A cadeia de certificados inclui o certificado EE e quaisquer certificados de CA que não estejam presentes no peer local.

O administrador de rede precisa garantir que todos os pares que participam de uma negociação de IKE tenham pelo menos uma CA de confiança comum em suas respectivas cadeias de certificados. O CA de confiança comum não precisa ser o CA raiz. O número de certificados na cadeia, incluindo certificados para EEs e o CA mais alto da cadeia, não pode exceder 10.

A partir do Junos OS Release 18.1R1, a validação de um peer IKE configurado pode ser feita com um servidor CA ou grupo de servidores CA especificados. Com cadeias de certificados, o CA raiz deve combinar com o grupo de CA confiável ou servidor CA configurado na política de IKE

No exemplo da hierarquia de CA mostrado, Figura 8o Root-CA é o CA de confiança comum para todos os dispositivos da rede. A Root-CA emite certificados de CA para os CAs de engenharia e vendas, identificados como Eng-CA e Sales-CA, respectivamente. A Eng-CA emite certificados de CA para os CAs de desenvolvimento e garantia de qualidade, identificados como Dev-CA e Qa-CA, respectivamente. O Host-A recebe seu certificado EE da Dev-CA, enquanto o Host-B recebe seu certificado EE da Sales-CA.

Figura 8: Hierarquia multinível para autenticação baseada em certificados

Cada dispositivo final precisa ser carregado com os certificados ca em sua hierarquia. O Host-A deve ter certificados Root-CA, Eng-CA e Dev-CA; Os certificados de Vendas-CA e Qa-CA não são necessários. O Host-B deve ter certificados Root-CA e Sales-CA. Os certificados podem ser carregados manualmente em um dispositivo ou inscritos usando o Processo simples de inscrição de certificados (SCEP).

Cada dispositivo final deve ser configurado com um perfil de CA para cada CA na cadeia de certificados. A saída a seguir mostra os perfis de CA configurados no Host-A:

A saída a seguir mostra os perfis de CA configurados no Host-B:

Vulnerabilidades de DDoS em implementações IKE

Quando o peer remoto (iniciador) envia uma mensagem SA_INIT, o peer local (responder) responde e aloca a memória para a estrutura da mensagem. Chamamos a sessão de sessão de IKE semi-aberta até que a autenticação aconteça com a ajuda da mensagem IKE_AUTH. Após os pares estabelecerem uma associação de segurança IKE (SA), a sessão se tornará uma sessão de IKE totalmente aberta.

Para entender as vulnerabilidades de DDoS IKEv2, vamos analisar algumas das maneiras pelas quais um invasor pode criar um vetor de ataque fácil contra as SAs IKE:

• Envie um grande número de mensagens de SA_INIT (sem IKE_AUTH mensagens) para as quais o invasor pode criar estruturas de associação de segurança IKE semi-abertas. O ataque faz com que o dispositivo utilize os recursos e se esconda a memória.

• Envie um grande número de pacotes de IKE_AUTH lixo com o SPI_i e SPI_r corretos no iniciador e no respondente, respectivamente. O dispositivo fica semmemória enquanto tenta descriptografar os pacotes.

• Envie pacotes de SA_INIT continuamente. O dispositivo fica sem memória enquanto tenta gerar chaves para os pacotes criptografados.

• Envie um grande número de solicitações rekey por segundo durante as sessões de IKE abertas completas.

• Envie um grande número de mensagens com identificadores de mensagens (IDs) distintos. O dispositivo Tfaz fila com todas as mensagens IKE recebidas e fica sem memória.

Como proteger as implementações IKE

Fornecemos uma infraestrutura robusta para mitigar e monitorar ataques DDoS para protocolos IKEv1 e IKEv2. Você pode se proteger contra os ataques em implementações de IKE quando seu firewall executa o processo iked (no junos-ike pacote) para o serviço VPN IPsec.

Proteção Aganhat Ataques DDoS

Você pode habilitar vários mecanismos de defesa contra os ataques DDoS durante o processo de criação da associação de segurança IKE. Esses mecanismos incluem a configuração de limitação de taxa e um período de retenção para os SAs IKE semiaberto e o gerenciamento das taxas de intercâmbio de entrada para as solicitações rekey. Fornecemos as seguintes medidas para garantir a proteção contra ataques DDoS em SAs IKE:

• Medidas de proteção fou SAs IKE semi-abertos:

  • O respondente não permite a configuração de SAS IKE semi-abertos por uma determinada duração. Você pode definir esse limite para que o respondente não configure os SAs até que ele atinja a duração do tempo limite. Para obter mais detalhes, veja session (Security IKE) a opção timeout.

  • Você pode definir um limite sobre as SAs IKE semi-abertas permitidas no respondente. Quando o número total de SAs IKE semiaberto chega à contagem máxima, o respondente rejeita novas conexões para SAs IKEv1 e IKEv2. Para obter mais detalhes, veja a opçãomax-count.session (Security IKE)

  • O respondente aplica valores limiares na contagem de sessões para SAs IKE semiaberto. Quando o número total de SAs IKE semiaberto atingiros valores limiares:

    • No caso dos SAs IKEv2, o respondente invoca o mecanismo de cookies para quaisquer novas conexões.

    • No caso dos SAs IKEv1, o respondente rejeita novas conexões.

    Para obter mais detalhes, veja a e reduce-timeoutsend-cookie as thresholdsopções em session (Security IKE).

  • O respondente pode descartar sessões duplicadas. Para obter mais detalhes, veja a opção discard-duplicate em session (Security IKE).

  • Você pode definir intervalos de backoff para fases de falha de autenticação e falha de iniciação. Para obter mais detalhes, veja session (Security IKE) as opções init-phase-failurebackoff-timeoutse auth-phase-failure.

• Para SAs IKE totalmente abertos:

  • Você pode configurar as taxas de solicitação de requisição de entrada máximas para reduzir as solicitações em um cenário dimensionado. Para obter mais detalhes, veja a opçãoincoming-exchange-max-rates.session (Security IKE) 

• O respondente pode bloquear uma sessão de IKE recebida dos pares com base no ID ID de IKE por pares. Para obter mais detalhes, veja blocklists (Security IKE).

• Para gateways dinâmicos, você pode definir um limite para o número de conexões no nível de configuração do gateway IKE usando a opção connections-limit. Para obter mais detalhes, veja gateway (Security IKE).

Para obter mais detalhes sobre como configurar essas opções, veja Configurar proteção contra ataques DDoS IKE.

Não oferecemos suporte:

• Proteção contra DDoS com serviço VPN IPsec baseado no processo kmd.

• Proteção contra ataques de codificação de certificados de Hash e URL , pois não oferecemos suporte a esses tipos de codificação.

Maneiras de monitorar ataques DDoS

Fornecemos os seguintes mecanismos para monitorar os ataques DDoS:

• Use o show security ike security-associations comando para listar todas as associaçõesde segurança IKE amadurecidas e não maduras. Para obter mais detalhes, veja mostrar as associações de segurança ike de segurança.

• Use o show security ike stats comando para exibir estatísticas globais de IKE do túnel VPN IPsec, como estatísticas em andamento, estabelecidas e expiradas. Para obter mais detalhes, veja as estatísticas de segurança ike.

• Use o show security ike active-peer comando para exibir detalhes das negociações bem-sucedidas da IKE com os pares remotos. Para obter mais detalhes, veja mostrar segurança ike active-peer.

• Use o show security ike peers in-progress comando para exibir os detalhes dos SAs IKE em andamento, incluindo os SAs IKE semi-abertos. Para obter mais detalhes, veja show security ike peers. Você também pode ver os detalhes dos peers bloqueados, com falha e de backoff usando este comando.

• Use o clear security ike peers comando para limpar os pares IKE que são desativados, bloqueados, com falha ou em andamento. Para obter mais detalhes, veja clear security ike peers.

• Para excluir uma associação de segurança IKE existente com colegas que precisa ser bloqueada de novas comunicações, use o clear security ike security-associations comando. Para obter mais detalhes, veja as associações de segurança ike de segurança claras.

• As mensagens de system log (syslog) iked IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF e IKE_GATEWAY_PEER_FAILED fornecem detalhes sobre as negociações bloqueadas, respaldadas e fracassadas do IKE com os pares remotos, respectivamente.

• Para segurança adicional, o Junos OS oferece serviços aos usuários para proteção contra ataques de sistema baseados em pacotes, como filtragem, contagem de sessões e limitação de taxas. Para obter mais detalhes, veja o comando de firewall show e a declaração de opção de ids no nível [edit security screen ids-option screen-name] de hierarquia.

Fragmentação de mensagens

A fragmentação de mensagens IKEv2, conforme descrito no RFC 7383, fragmentação de mensagens do Protocolo de Troca de Chaves da Internet Versão 2 (IKEv2), permite que o IKEv2 opere em ambientes onde fragmentos de IP podem ser bloqueados e os pares não seriam capazes de estabelecer uma associação de segurança IPsec (SA). A fragmentação do IKEv2 divide uma grande mensagem IKEv2 em um conjunto de menores para que não haja fragmentação no nível de IP. A fragmentação ocorre antes que a mensagem original seja criptografada e autenticada, de modo que cada fragmento seja criptografado e autenticado separadamente. No receptor, os fragmentos são coletados, verificados, descriptografados e mesclados na mensagem original.

Para que a fragmentação do IKEv2 ocorra, ambos os pares de VPN devem indicar o suporte à fragmentação, incluindo a carga de notificação IKEV2_FRAGMENTATION_SUPPORTED na troca de IKE_SA_INIT. Se ambos os pares indicarem suporte à fragmentação, cabe ao iniciador da troca de mensagens determinar se a fragmentação do IKEv2 é usada ou não.

Em firewalls da Série SRX, um máximo de 32 fragmentos são permitidos por mensagem IKEv2. Se o número de fragmentos de mensagem IKEv2 a serem enviados ou recebidos exceder 32, os fragmentos serão descartados e o túnel não estiver estabelecido. A retransmissão de fragmentos de mensagens individuais não é suportada

Configuração

Nos firewalls da Série SRX, a fragmentação do IKEv2 é habilitada por padrão para mensagens IPv4 e IPv6. Para desativar a fragmentação do IKEv2, use a disable declaração no nível [edit security ike gateway gateway-name fragmentation] de hierarquia. Você também pode usar a size declaração para configurar o tamanho do pacote em que as mensagens são fragmentadas; o tamanho do pacote varia de 500 a 1300 bytes. Se size não estiver configurado, o tamanho padrão do pacote é de 576 bytes para tráfego IPv4 e 1280 bytes para tráfego IPv6. Um pacote IKEv2 que é maior do que o tamanho do pacote configurado é fragmentado.

Depois que a fragmentação do IKEv2 é desativada ou habilitada ou o tamanho do fragmento de pacote é alterado, os túneis VPN hospedados no gateway IKE são desativados e os SAs IPsec são desativados.

Advertências

Os recursos a seguir não são suportados com a fragmentação do IKEv2:

• Caminho MTU Discovery.

• SNMP.