Visão geral do grupo VPNv2

Entendendo a VPN de grupo v2

A VPN de grupo é um grupo confiável para eliminar túneis ponto a ponto e seu roteamento de sobreposição associado. Todos os membros do grupo compartilham uma associação de segurança comum (SA), conhecida como SA de grupo (GSA). O GSA permite que os membros do grupo descriptografem o tráfego que foi criptografado por qualquer outro membro do grupo. A partir do Junos OS Release 18.2R1, confirmamos a redundância de VPN de grupo com o protocolo de redundância de serviço [SRD] em execução nos roteadores MX. Os roteadores MX com redundância entre eles atuam como membros do Group VPN. Para obter mais detalhes sobre o protocolo de redundância de serviço, consulte Visão geral do daemon de redundância de serviço.

A partir do Junos OS Release 15.1, o Junos OS oferece suporte ao Group VPNv2. O Group VPNv2 é uma categoria de VPN que elimina a necessidade de túneis VPN ponto a ponto em uma arquitetura de malha. É um conjunto de recursos necessários para proteger o tráfego unicast em uma WAN privada que se origina ou flui por meio de um roteador.

O grupo VPNv2 introduz o conceito de um grupo confiável para eliminar túneis ponto a ponto e seu roteamento de sobreposição associado. Todos os membros do grupo compartilham uma associação de segurança comum (SA), também conhecida como SA de grupo. Isso permite que os membros do grupo descriptografem o tráfego que foi criptografado por qualquer outro membro do grupo.

O grupo VPNv2 oferece as seguintes vantagens:

• Oferece segurança de dados e autenticação de transporte, ajudando a atender à conformidade de segurança e à regulamentação interna, criptografando todo o tráfego da WAN.

• Permite malhas de rede de alta escala e elimina o gerenciamento complexo de chaves ponto a ponto com chaves de criptografia de grupo.

• Reduz o número de alterações de endpoint que precisam ser feitas devido a alterações de membros do grupo ou alterações de política.

• Mantém a inteligência de rede, como conectividade de malha completa, caminho de roteamento natural e qualidade de serviço (QoS) em redes MPLS.

• Concede o controle de associação autenticado com um servidor de chaves centralizado.

• Permite a criptografia e a descriptografia do tráfego entre todos os membros do grupo definidos na política de grupo.

• Ajuda a garantir baixa latência e jitter, permitindo comunicações diretas em tempo integral entre locais, sem exigir transporte por um hub central.

• Reduz as cargas de tráfego em equipamentos de instalações do cliente (CPE) e dispositivos de criptografia de borda do provedor (PE) usando a rede principal para replicação de tráfego, evitando a replicação de pacotes em cada site peer individual.

VPN em grupo v2 e VPN IPsec padrão

O Group VPNv2 é construído com base em tecnologias baseadas em padrões que integram roteamento e criptografia na rede. Uma SA de segurança IPsec é um acordo unidirecional entre participantes de VPN que define as regras a serem usadas para algoritmos de autenticação e criptografia, mecanismos de troca de chaves e comunicações seguras.

As implantações tradicionais de VPN IPsec resolvem o problema de proteger o tráfego entre gateways na rede criando uma rede overlay baseada no uso de túneis ponto a ponto. O tráfego transportado por esses túneis é normalmente criptografado e autenticado para fornecer integridade e confidencialidade dos dados. Os membros seguros do grupo são gerenciados por meio do protocolo de Domínio de Interpretação do Grupo (GDOI). A solução GDOI adota uma abordagem diferente, desassociando o problema de criptografia e autenticação do transporte. Ao fazer isso, as soluções baseadas em GDOI fornecem uma maneira de criptografar as comunicações de ramo a ramo sem a necessidade de configurar túneis de ramo a ramo.

Com as implementações de VPN atuais, o SA é um túnel ponto a ponto entre dois pontos finais. O grupo VPNv2 estende a arquitetura IPsec para oferecer suporte a SAs compartilhadas por um grupo de roteadores (consulte a Figura 1). Um servidor de chaves distribui chaves e políticas para todos os roteadores membros registrados e autenticados. Ao distribuir as políticas de um ponto centralizado e compartilhar a mesma associação de segurança de grupo (todo o grupo tem uma única SA de Fase 2) com membros autenticados do grupo, a distribuição e o gerenciamento de chaves são bastante simplificados.

O grupo VPNv2 é uma arquitetura cliente/servidor. Todos os membros têm um IKE SA de Fase 1 exclusivo com o servidor de chaves. Portanto, se houver n membros, há um total de n SAs IKE da Fase 1. No entanto, todo o grupo compartilha uma única SA de Fase 2.

No IPsec tradicional, os endereços de endpoint do túnel são usados como uma nova origem e destino de pacotes. O pacote é então roteado pela infraestrutura IP, usando o endereço IP de origem do ponto final de criptografia e o endereço IP de destino do ponto final de descriptografia. No caso da VPN de grupo, os pacotes de dados protegidos por IPsec preservam os endereços de origem e destino originais do host no cabeçalho IP externo para preservar o endereço IP. Isso é conhecido como preservação de cabeçalho de túnel. As maiores vantagens da preservação do cabeçalho do túnel é a capacidade de rotear pacotes criptografados usando a infraestrutura de roteamento de rede subjacente.

Entendendo o Protocolo GDOI

O protocolo GDOI (Group Domain of Interpretation) descrito no RFC 6407 é usado para distribuir um conjunto de chaves criptográficas e políticas para um grupo de dispositivos. O GDOI é definido como o Domínio de Interpretação (DOI) do Internet Segurança Association Key Management Protocol (ISAKMP) para gerenciamento de chaves de grupo. Em um modelo de gerenciamento de grupo, o protocolo GDOI opera entre um membro do grupo e um controlador de grupo ou servidor de chaves (GC/KS) e gerencia associações de segurança de grupo e chaves de grupo para um conjunto de participantes de segurança. O ISAKMP define duas fases de negociação. O GDOI é um protocolo de Fase 2 protegido por uma associação de segurança ISAKMP de Fase 1. O IKEv1 é especificado no RFC 6407 como um protocolo de Fase 1.

O GDOI introduz duas chaves de criptografia diferentes:

• Chave de criptografia de chave (KEK) — usada para proteger o plano de controle. KEK é o nome da chave usada pelos membros do grupo para descriptografar mensagens de rechaveamento do GC/KS. Essa chave faz parte da SAK (Chave de Criptografia de Chave) da Associação de Segurança.

• Chave de criptografia de tráfego (TEK) — usada para proteger o plano de dados. TEK é o nome da chave usada pelos membros do grupo para criptografar ou descriptografar a comunicação entre outros membros do grupo. Essa chave faz parte da Chave de Criptografia de Transporte da Associação de Segurança (SA TEK).

Assim como acontece com o IPsec padrão, todas as chaves têm um tempo de vida e precisam ser recodificadas. As chaves distribuídas por meio do GDOI são chaves de grupo e são usadas por todo o grupo.

As SAs de grupo e o gerenciamento de chaves são tratados por meio de dois tipos de trocas de GDOI:

• groupkey-pull— Essa troca permite que um membro solicite SAs e chaves compartilhadas pelo grupo a partir do servidor.

  No método pull, o membro do grupo solicita a SA do grupo e a política do servidor de chaves. Essa solicitação é protegida pelo IKE SA.

  O groupkey-pull é o primeiro intercâmbio no protocolo GDOI e é usado para registro de membros do grupo no GC/KS. O membro do grupo especifica o grupo no qual deseja se registrar e o GC/KS envia todas as SAs e chaves de grupo necessárias para o membro do grupo se o membro estiver autorizado a ingressar no grupo. A troca completa é protegida por uma Fase 1 SA (IKEv1 SA), que é estabelecida com IKEv1 antes do início da groupkey-pull troca. O groupkey-pull faz parte da Fase 2 do protocolo GDOI.

• groupkey-push— Essa troca é uma única mensagem de rechaveamento que permite que o servidor envie SAs e chaves de grupo aos membros antes que as SAs de grupo existentes expirem. As mensagens de rechaveamento são mensagens não solicitadas enviadas do servidor para os membros.

  O groupkey-push é o segundo intercâmbio no protocolo GDOI e é iniciado pelo GC / KS para todos os membros registrados do grupo. A Tabela 2 mostra os payloads que o membro do grupo da Série MX espera receber nas groupkey-push mensagens.

  Tabela 2: Payloads de mensagens groupkey-push

  payload	Descrição
  política associada a grupo (GAP)	Um payload GAP permite a distribuição de políticas para todo o grupo, como instruções sobre quando ativar e desativar SAs. Esse payload contém valores para atraso de tempo de ativação (ATD) e atraso de tempo de desativação (DTD) para a chave de criptografia de tráfego (TEK), bem como tipo de janela de protocolo de detecção atrasada de entrega de IP e tamanho de janela para o tráfego IPsec.
  Chave de criptografia de transporte da Associação de Segurança (SA TEK)	Seletores de tráfego.
  Chave de criptografia de chave de associação de segurança (SAK) (opcional)	A associação de segurança (SA) para a chave de criptografia de chave (KEK). Também conhecido como SA KEK. Observação: groupkey-push As mensagens que não incluem as cargas opcionais ainda são mensagens válidas.
  chave de criptografia de tráfego (TEK) (opcional)	Chave para criptografar o tráfego de dados entre os membros do grupo.
  chave de criptografia de chave (KEK) (opcional)	Usado para proteger o TEK.

  A groupkey-push troca é protegida por um SA KEK (SAK), que é instalado durante a groupkey-pull troca. O groupkey-push faz parte da Fase 2 do protocolo GDOI.

Em alguns casos, o GC/KS pode querer receber mensagens de confirmação de push de chave de grupo de membros do grupo. As mensagens de confirmação de push dos membros do grupo confirmam que o membro recebeu a mensagem e tomou medidas em sua política. O GG/KS também pode usar a confirmação para determinar quais membros do grupo estão recebendo a política de grupo atual e quais membros do grupo não estão mais participando do grupo. A partir do Junos OS 19.2R1, Junos OS envia uma mensagem de confirmação com soma de verificação SHA-256 quando recebe uma mensagem de push de chave de grupo com um valor de KEK_ACK_REQUESTED padrão de 9 na carga útil SA KEK, conforme definido no RFC 8263 ou um valor de KEK_ACK_REQUESTED de 129 usado em servidores de chaves mais antigos.

Protocolo GDOI e VPN de grupo VPNv2

Group VPNv2 é o nome da tecnologia de segurança implementada nas plataformas de roteador da Juniper Networks. O Group VPNv2 usa o protocolo GDOI (RFC 6407) como base, além de outras funcionalidades.

A tecnologia VPN de grupo é baseada no protocolo GDOI para lidar com a funcionalidade mais importante. Esse protocolo é especificado no RFC 6407 e define um Domínio de Interpretação (DOI) ISAKMP para gerenciar SAs e chaves de grupo para um grupo de participantes de segurança. Assim, todos os membros do grupo compartilham informações idênticas para criptografar e descriptografar o tráfego entre si. A criação, o gerenciamento e a distribuição de SAs de grupo e chaves de grupo são centralizados e executados pelo GC/KS. A Figura 2 fornece uma breve visão geral da funcionalidade Group VPNv2 usando GDOI.

Figura 2: VPN de grupo usando GDOI

Os membros do grupo usam o protocolo ESP (Encapsulating Segurança Payload) no modo de túnel para proteger o tráfego. No entanto, na VPN de grupo, o modo de túnel é modificado. Como não há associação direta entre os membros do grupo, não é necessário usar endereços IP especiais no cabeçalho IP externo (ou seja, endereços IP de gateways IPsec). Cada membro do grupo pode descriptografar o tráfego de todos os outros membros do grupo. Assim, o cabeçalho de IP interno é copiado para o cabeçalho de IP externo, e a infraestrutura de roteamento subjacente e a infraestrutura de QoS podem ser usadas. Esse recurso é chamado de preservação de cabeçalho e é mostrado na Figura 3.

Figura 3: Preservação do cabeçalho

Para obter SAs e chaves de grupo, o membro do grupo deve se registrar no GC/KS para um grupo específico. O resultado é um IKEv1 SA, que só é necessário para proteger o processo de registro. Após o registro, o membro do grupo tem todas as informações para se comunicar com os outros membros do grupo (SA TEK), bem como as informações para descriptografar com sucesso as mensagens de rechaveamento (SAK). O GC/KS envia mensagens de rechaveamento antes que o tempo de vida do SA TEK ou do SAK expire. Também é possível enviar uma atualização SA TEK, bem como uma atualização SAK na mesma mensagem de rechaveamento. A SA IKEv1 não é mais necessária e é excluída após a expiração do tempo de vida (sem rechaveamento IKEv1).

Tráfego VPNv2 em grupo

O tráfego de grupo VPNv2 inclui:

• Control-plane-traffic — Tráfego dos membros do grupo para o GC/KS na implantação do Grupo VPNv2 somente com o protocolo GDOI.

• Data-plane-traffic — Tráfego entre os membros do grupo na implantação do grupo VPNv2 apenas com o protocolo ESP, que já é conhecido do IPsec.

Associação de Segurança do Grupo

Ao contrário das soluções tradicionais de criptografia IPsec, o Group VPN usa o conceito de associação de segurança de grupo. Uma SA de grupo é semelhante a uma SA em termos de funcionalidade. As SAs de grupo são compartilhadas entre todos os membros do grupo de um grupo GDOI comum. Todos os membros do grupo VPN de grupo podem se comunicar uns com os outros usando uma política de criptografia comum e uma SA de grupo compartilhada. Com uma política de criptografia comum e uma SA de grupo compartilhada, não há necessidade de negociar o IPsec entre os membros do grupo. Isso reduz a carga de recursos sobre os membros do grupo. Os problemas tradicionais de escalabilidade do IPsec (número de túneis e SAs associadas) não se aplicam aos membros do grupo de VPN de grupo.

Controlador de grupo/servidor de chaves

Um controlador de grupo ou servidor de chaves (GC/KS) é um dispositivo usado para criar e manter o plano de controle do Group VPNv2. É responsável pela criação e distribuição de SAs de grupo e chaves de grupo. Todas as informações que os membros do grupo precisam para se comunicar com outros membros do grupo são fornecidas pelo GC/KS. Todas as políticas de criptografia, como tráfego interessante, protocolos de criptografia, associação de segurança, temporizadores de rechaveamento e assim por diante, são definidas centralmente no GC/KS e são enviadas para todos os membros do grupo no momento do registro. Os membros do grupo se autenticam com o GC/KS usando o IKE Fase 1 e, em seguida, baixam as políticas de criptografia e as chaves necessárias para a operação de VPN de grupo. O GC/KS também é responsável por atualizar e distribuir as chaves.

Membro do grupo

Um membro do grupo é um dispositivo de endpoint IPsec usado para o processo de criptografia de tráfego e é responsável pela criptografia e descriptografia reais do tráfego de dados. Um membro do grupo é configurado com parâmetros da Fase 1 do IKE e informações de GC/KS. As políticas de criptografia são definidas centralmente no GC/KS e baixadas para o membro do grupo no momento do registro bem-sucedido. Cada membro do grupo determina se o tráfego de entrada e saída deve ser descriptografado ou criptografado (usando sua SA) com base em sua associação ao grupo.

Do ponto de vista da funcionalidade, um membro do grupo é semelhante a um gateway IPsec. No entanto, as SAs no IPsec normal existem entre dois gateways IPsec. No GDOI, o membro do grupo se registra no GC/KS para participar da VPN do grupo. Durante o registro, o membro do grupo fornece a ID do grupo ao GC/KS para obter as respectivas políticas, SAs e chaves necessárias para esse grupo. O rechaveamento é realizado pelos membros do grupo através do groupkey-pull método (re-registro) ou pelo GC/KS através do groupkey-push método.

Proteção anti-reprodução para tráfego VPNv2 em grupo

Como a comunicação VPN de grupo é essencialmente uma comunicação de qualquer para qualquer na mesma associação de segurança compartilhada, o uso de números de sequência para proteção anti-reprodução não funciona. Por isso, o Junos OS oferece suporte a uma especificação de rascunho IETF para um mecanismo anti-repetição baseado em tempo, draft-weis-delay-detection-01. Está disponível em http://tools.ietf.org/html/draft-weis-delay-detection-01 .

Para implementar esse recurso, os roteadores membros da Série MX fazem uso de um novo cabeçalho de carimbo de data/hora do protocolo de detecção de atraso de entrega IP dentro do pacote. Consulte Implementando o protocolo de detecção de atraso de entrega de IP (proteção anti-reprodução baseada em tempo) para obter detalhes.

Abertura parcial em roteadores membros da Série MX

Os membros do grupo em uma VPN de grupo contam com o GC/KS para gerar material de chave para a SA compartilhada. Portanto, a conectividade entre os membros do grupo e os GC/KSs é necessária para proteger inicialmente o tráfego e proteger continuamente o tráfego em eventos de rechaveamento. No caso de falha de comunicação entre o membro do grupo e o GC/KS, o comportamento padrão dos membros do grupo é interromper o encaminhamento de tráfego. Isso é conhecido como falha fechada.

Uma opção de configuração não padrão está disponível para permitir que algum tráfego especificamente definido flua pelo membro do grupo sem ser criptografado até que o membro possa entrar em contato com o GC/KS e recuperar a SA ativa. Isso é conhecido como falha parcial aberta.

O recurso de falha parcial requer uma opção de configuração de política que cria uma regra no membro do grupo da Série MX aplicável para um grupo VPNv2 específico definido pelos endereços de origem e destino. Essa regra de falha aberta está ativa somente quando o grupo SA está no estado desativado devido à falha de conectividade com o servidor de chaves. O tráfego que normalmente passaria pela VPN de grupo, mas não corresponde à regra de falha aberta, é descartado. Mais de uma regra de abertura de falha pode ser definida para o objeto VPN de grupo. Se nenhuma regra de falha for configurada, o recurso de falha aberta será desabilitado.

Habilitando o grupo VPNv2

Um conjunto de serviços é usado para habilitar o Grupo VPNv2 em uma interface específica em roteadores da Série MX aplicáveis.

[edit services]
service-set service-set-name {
    interface-service {
        service-interface service-interface-name;
    }
}
ipsec-group-vpn vpn-name;

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name;
                }
                output {
                    service-set service-set-name;
                }
            }
            address 10.0.30.2/30;
        }
    }
}

Registrando um membro do grupo

O registro do membro do grupo no servidor é iniciado quando a instrução é configurada ipsec-group-vpn para um conjunto de serviços e a interface de serviço está ativa. Quando a interface de serviço fica inativa, todas as SAs de grupo associadas a essa interface são limpas e nenhum registro é disparado para essas VPNs de grupo até que a interface seja ativada.

O registro de membro do grupo envolve o estabelecimento de IKE SA com o GC/KS, seguido por uma groupkey-pull troca para baixar as SAs e as chaves de tráfego para o identificador de grupo especificado.

Rechaveamento de um membro do grupo (método groupkey-push)

O GG/KS enviará uma mensagem unicast groupkey-push aos membros registrados do grupo para:

• Envie novas chaves de criptografia de chave (KEKs) ou chaves de criptografia de tráfego (TEKs).

  As mensagens push podem conter todos ou apenas alguns dos elementos de carga mostrados na Tabela 2. Quando a carga GAP contém SAs antigas e novas SAs de substituição, o roteador membro do grupo aplicará os valores ATD e DTD como uma rechaveamento normal por meio de push. Se não houver nenhum valor ATD na atualização, o roteador membro instala as novas SAs imediatamente. Se não houver valor DTD, as SAs antigas permanecerão em vigor até sua expiração.

• Atualize a política associada ao grupo (GAP) para uma SA existente.

  Um GC/KS pode enviar uma mensagem push de unicast para atualizar a configuração para os membros do grupo a qualquer momento. O payload do GAP pode incluir mudanças de configuração no protocolo de detecção de atraso de entrega de IP, algoritmo de criptografia, tempo de vida e assim por diante. A configuração atualizada é aplicada imediatamente ou com atraso. Os valores de ATD e DTD são usados para atingir o tempo para a ativação do novo TEK e exclusão do TEK existente, respectivamente. Se o tempo de vida do TEK existente tiver que ser reduzido, o valor DTD será definido de acordo com a mensagem push. O novo TEK na mensagem de push é ativado com base no valor do ATD na carga.

• Envie notificações de chave de exclusão para TEK ou KEK.

  O GC/KS pode enviar a carga de notificação de exclusão opcional na mensagem de push para excluir chaves e SAs no membro. A mensagem por push contém a ID do protocolo que indica se a notificação de exclusão é para TEK ou KEK. O roteador membro do grupo exclui a chave com base no ID do grupo e no valor de SPI contidos no payload. A exclusão de um TEK ou KEK específico pode ser feita com um valor de atraso especificado no atributo DTD. Se o valor de atraso for 0 e o payload contiver um SPI específico, o TEK ou KEK correspondente será excluído imediatamente. Se todos os TEKs ou KEKs (ou ambos) precisarem ser excluídos do grupo, o valor de SPI será definido como 0 para a ID de protocolo correspondente na carga.

• Remova um roteador membro da VPN de grupo no VPN de grupo

  As mensagens push são usadas para permitir que o GC/KS exclua membros da VPN de grupo. Em um caso, o GC/KS envia uma mensagem de rechaveamento apenas com as SAs antigas e um valor de DTD menor. O roteador membro do grupo instala o novo valor DTD menor. Como não recebeu novas chaves SA, o roteador membro tenta se registrar novamente usando o groupkey-pull método. Essa tentativa de novo registro é rejeitada pelo GC/KS, excluindo assim o membro da VPN de grupo. No segundo caso, o GC/KS envia uma carga de exclusão para o SPI do SA antigo. O roteador membro do grupo exclui a SA imediatamente e tenta se registrar novamente usando o groupkey-pull método. Essa tentativa de novo registro é rejeitada pelo GC/KS, excluindo assim o membro da VPN de grupo.

Os membros registrados do grupo da Série MX enviam uma mensagem PUSH ACK unicast de volta ao GC/KS para confirmar o recebimento da mensagem push original.

Rechaveamento de um membro do grupo (método groupkey-pull)

Para rechaveamento de membros do grupo, usando o groupkey-pull método, os membros do grupo normalmente se registram novamente no GC/KS quando há entre 7% e 5% restantes no tempo de vida suave TEK ou KEK existente. Se o IKE SA existente estiver disponível, ele será usado na mensagem de pull. Depois que o GC/KS responde com uma nova chave, a chave antiga e a nova chave podem ser usadas para descriptografia. No entanto, a nova chave não é usada para criptografia até que 30 segundos de vida da chave antiga sejam restantes. Se a SA do IKE existente não estiver disponível, a mensagem de pull resultará em novas negociações de IKE entre o membro do grupo e o GC/KS.

Ao receber a mensagem de pull sobre uma VPN de grupo específica do membro do grupo, o GC/KS responde com todos os TEKs e o KEK desse grupo.

Se alguma SA existente não estiver incluída na resposta do GC/KS, as SAs ausentes serão excluídas pelo membro do grupo.

Tomando como exemplo, o GC/KS é configurado com um tempo de vida de 3600 segundos e está conectado a um membro do grupo sem retransmissão. Com base na configuração do servidor, o GC/KS gera uma nova chave quando 10% do tempo de vida é restante. O membro do grupo, no entanto, se registra novamente no GC / KS quando 5% a 7% da vida útil restam.

A Figura 4 representa o processo de rechaveamento entre o GC/KS e o membro do grupo.

Figura 4: Rechaveamento de membros do grupo

Autenticando um membro do grupo

O Junos OS não oferece suporte a infraestrutura de chave pública (PKI) para VPN de grupo no VPN de grupo VPNv2. Como resultado, as chaves pré-compartilhadas são usadas para autenticação de membros do grupo.

Fragmentação do tráfego VPNv2 em grupo

Devido à funcionalidade de preservação de cabeçalho e ao uso da infraestrutura de roteamento subjacente, é necessário fragmentar os pacotes antes que a criptografia ocorra (se ela não puder ser evitada).

Portanto, a pré-fragmentação é suportada e recomendada para todas as implantações.

Para evitar a pós-fragmentação, defina as clearopções , sete copy para o bit DF na configuração do Grupo VPNv2.

Com base nessa configuração de sinalizador, o cabeçalho IPsec tem o df-bit conjunto como clear, setou copy do pacote interno.

[edit]
security {
    group-vpn {
        member {
            ipsec {
                vpn group-vpn-name {
                    df-bit clear;
                }
            }
        }
    }
}

Criptografando o tráfego VPNv2 do grupo

Os membros do grupo criptografam o tráfego com base nas SAs e chaves de grupo fornecidas pelo GC/KS. O caminho de criptografia do Grupo VPNv2 é o seguinte:

1. O pacote recebido pelo Mecanismo de Encaminhamento de Pacotes é verificado em relação a uma correspondência de fluxo. Se uma correspondência for encontrada, o pacote será processado e transmitido posteriormente.

2. Se uma correspondência não for encontrada, uma pesquisa de regra será executada. Se uma correspondência for encontrada, um fluxo será criado e o pacote será processado e transmitido posteriormente.

3. Se a pesquisa de regra falhar, o pacote será descartado.

Descriptografando o tráfego VPNv2 do grupo

Depois que o registro for bem-sucedido e as SAs de VPN de grupo forem instaladas, uma sessão ESP será criada. O grupo VPNv2 cria a sessão ESP com um IP de origem e destino zero. Como a sessão ESP já foi criada na instalação SA, espera-se que os pacotes correspondam à sessão ESP existente.

O caminho de descriptografia do Grupo VPNv2 é o seguinte:

1. O pacote recebido pelo Mecanismo de Encaminhamento de Pacotes passa por uma verificação de fragmentação. Se o pacote estiver fragmentado, ele será montado para processamento posterior.

2. Após a montagem do pacote ou se o pacote não estiver fragmentado, um IP de origem e destino zero será usado na pesquisa de fluxo de descriptografia de 5 tuplas. Se uma correspondência for encontrada, o pacote será processado e transmitido posteriormente.

3. Se a pesquisa de fluxo de descriptografia falhar, o pacote será verificado em relação a um fluxo SPI com IP de origem e destino zero.

4. Se a pesquisa de fluxo SPI falhar, o pacote será descartado.

5. Se uma correspondência de fluxo SPI for encontrada, um fluxo de descriptografia será criado para evitar a pesquisa de fluxo SPI para pacotes subsequentes.

Configurando uma instância de roteamento para o grupo VPNv2

As instâncias de roteamento têm suporte para controle e tráfego de dados. Para habilitar o suporte à instância de roteamento no tráfego do plano de controle para que um membro do grupo alcance o GC/KS em uma determinada instância de roteamento VRF, adicione a routing-instance declaração no nível da [edit security group-vpn member ike gateway gateway-name local-address address] hierarquia.

Nenhuma CLI adicional é necessária para suportar uma instância de roteamento para pacotes de plano de dados, pois ela é determinada com base na interface de mídia na qual o conjunto de serviços é aplicado.

Estabelecendo vários grupos, políticas e SAs

O Junos OS oferece suporte para uma VPN de grupo por serviço definido no VPN de grupo v2. No entanto, vários conjuntos de serviços podem ser criados para oferecer suporte a vários grupos em uma instância de roteamento. Várias SAs podem ser configuradas por grupo. No entanto, não há suporte para várias políticas para a mesma chave de tráfego/SPI. Se o servidor enviar duas políticas para o mesmo TEK, elas deverão ser emparelhadas para serem aceitas, por exemplo, AB e BA, onde A e B são endereços IP ou sub-redes. Se várias políticas não emparelhadas para um determinado TEK forem recebidas, o registro falhará e uma mensagem de log do sistema será gerada.

Conectando-se com vários GC/KSs cooperativos

Para que um membro do grupo trabalhe com um GC/KS no modo cooperativo, a configuração é estendida para permitir um máximo de quatro servidores na lista de servidores.

Durante a redigitação ao usar o groupkey-pull método, o membro do grupo tenta se conectar ao GC/KS. Quando a conexão com o GC/KS falha, o membro do grupo tenta se reconectar ao GC/KS. Após três tentativas com um intervalo de 10 segundos, se a conexão com o GC/KS não for restaurada, o membro do grupo tentará estabelecer uma conexão com o próximo servidor disponível na lista de servidores. Esse processo é repetido até que o membro do grupo se conecte a um GC/KS. Durante esse tempo, as SAs GDOI não expiradas nos membros do grupo não são limpas, portanto, o tráfego da VPN de grupo não é afetado. O intervalo de tempo entre o rechaveamento e a expiração do tempo de vida rígido fornece tempo suficiente para os membros do grupo se conectarem ao próximo servidor disponível, nesses casos.

Implementação do protocolo de detecção de atraso de entrega de IP (proteção anti-reprodução baseada em tempo)

Não há nenhuma configuração necessária para implementar o protocolo de detecção de atraso de entrega de IP. Os membros do grupo da Série MX obtêm o tamanho da janela de repetição a ser usado como parte da carga útil do GAP em mensagens push ou pull do servidor de chaves. Se o tamanho da janela recebida for 0, a proteção anti-reprodução baseada em tempo será desativada.

Se o protocolo de detecção de atraso de entrega de IP estiver habilitado, o remetente adicionará seu carimbo de data/hora atual e criptografará o pacote. O receptor descriptografa o pacote e compara sua hora atual com o carimbo de data/hora no pacote. Os pacotes que estão fora do tamanho da janela são descartados. Por isso, todos os membros do grupo devem ter seus relógios sincronizados usando o Network Time Protocol (NTP).

Detecção de atraso de entrega de IP Os tempos do protocolo são medidos em segundos. Consulte IP Delivery Delay Detection Protocol-draft-weis-delay-detection-01 para obter mais informações.

Alterando a configuração do grupo VPNv2

A maioria das alterações de configuração do Group VPNv2 resulta na exclusão de SAs existentes e no novo registro. Isso aciona o download da fase 1 e do SA com novas chaves de tráfego.

Ignorando a configuração do grupo VPNv2

Se determinado tráfego, como um protocolo de roteamento, precisar ignorar uma VPN de grupo no VPN de grupo Os pacotes que correspondem ao filtro de serviço não chegam ao PIC para processamento de serviço e são encaminhados diretamente ao Mecanismo de Roteamento.

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name service-filter filter-name;
                }
                output {
                    service-set service-set-name service-filter filter-name;
                }
            }
        }
    }
}

Implementação de abertura parcial em roteadores membros da Série MX

Por padrão, os pacotes são descartados se um roteador membro do grupo não conseguir obter SAs do GC/KS devido à perda de conectividade. Se você quiser permitir que algum tráfego passe sem criptografia no caso de uma falha de comunicação entre o membro do grupo e o GC/KS, deverá configurar uma fail-open regra noedit security group-vpn member ipsec vpn vpn-name nível de [] hierarquia.

As regras de falha aberta serão aplicadas ao tráfego somente em caso de perda de conectividade do servidor. As regras de falha aberta serão desativadas assim que a conectividade for restaurada e as chaves forem recebidas do GC/KS.

[edit security group-vpn member ipsec vpn vpn-name]
fail-open {
    rule rule-name{
        source-address source-ip-address
            destination-address destination-ip-address}
        }
    }

Um máximo de 10 regras de falha aberta podem ser configuradas para qualquer grupo.

Parâmetros de IPsec do GDOI suportados

Cada grupo GDOI tem um ID exclusivo. Ele é usado como uma base comum entre o GC/KS e o membro do grupo para se comunicar sobre SAs de grupo e chaves de grupo.

Durante o processo de registro, o GC/KS envia Segurança chaves de criptografia de transporte de associação (SA TEKs) para os membros do grupo. Todos os parâmetros relativos à política de segurança de todo o grupo são configurados no GC/KS. O SA TEK é usado pelos membros do grupo para proteger o tráfego trocado entre si. A Tabela 3 mostra os parâmetros do SA TEK.

Além dos algoritmos criptográficos, o tráfego, que deve ser criptografado pelos membros do grupo, faz parte da política SA TEK (seletor de tráfego).

As instruções a seguir podem ser usadas em um membro do grupo da Juniper Networks. Assim, os endereços devem ser especificados no nível de hierarquia do IKE. A enumeração também é priorizada. Assim, na configuração de exemplo a seguir, o KS1 é contatado antes do KS2.

[edit security]
group-vpn {
    member {
        ike {
            gateway gateway-name {
                ike-policy policy-name;
                server-address <IP_KS1> <IP_KS2> <IP_KS3> <IP_KS4>;
                local-address <IP_GM> routing-instance routing-instance-name;
            }
        }
        ipsec {
            vpn vpn-group-name {
                ike-gateway gateway-name;
                fail-open {
                    rule rule-name {
                    source-address 198.51.100.1/24 
                    destination-address 192.0.2.1/24 
                    }
                }
                group group-ID;
                match-direction output;
            }
        }
    }
}

Parâmetros GDOI IKEv1 suportados

Os padrões IKEv1 mencionados acima são configurados da seguinte forma:

Aplicação de políticas dinâmicas

As input opções e output na ipsec-group-vpn instrução especificam se as políticas dinâmicas recebidas do servidor são usadas quando a interface na qual o conjunto de serviços é aplicado é a interface de entrada ou saída. Isso fornece flexibilidade para especificar regras diferentes nas direções de entrada e saída.

Suporte a TOS e DSCP

Os bits de tipo de serviço (TOS) e pontos de código DiffServ (DSCP) são copiados do pacote interno para o pacote ESP.

Interoperabilidade dos membros do grupo

A implementação do GDOI pela Cisco é chamada de VPN de transporte de criptografia de grupo (GET). Embora a VPN de grupo v2 no Junos OS e a VPN GET da Cisco sejam ambas baseadas na RFC 6407, o domínio de interpretação de grupo, existem algumas diferenças de implementação que você precisa estar ciente ao implantar o GDOI em um ambiente de rede que inclui dispositivos de segurança e roteamento da Juniper Networks e roteadores Cisco. Para obter mais informações, consulte as notas de versão atuais do Junos OS.

A interoperabilidade do VPN v2 em grupo é a seguinte:

• O Junos OS oferece suporte de interoperabilidade com o suporte Cisco IOS GC/KS.

• O Junos OS não oferece suporte para interoperabilidade de VPN de grupo com o servidor VPN de grupo da Série SRX.

  Tabela 5: Interoperabilidade do VPNv2 em grupo

  Membro do grupo	Membro do Grupo SRX	Membro da VPN do MX Group	Membro do Cisco Group	SRX GC	SRX KS	Cisco GC/KS
  Membro da VPN do MX Group	Não	Sim	Sim	Não	Sim	Sim
  Membro do Grupo SRX	Sim	Não	Não	Sim	Sim	Sim

O Junos OS não suporta a política de negação usada em um servidor Cisco GC/SK para adicionar uma exceção à política de grupo. Como solução alternativa, isso pode ser feito configurando regras de firewall em um membro do grupo da Série MX. Além disso, os membros do grupo do Junos OS podem trabalhar com a política de negação não falhando na negociação e simplesmente ignorando o conteúdo. Isso permite que os administradores do sistema gerenciem facilmente redes nas quais os membros do grupo Cisco e do grupo Junos OS coexistem.

Limitações do VPN de grupo

O Junos OS Group VPNv2 não oferece suporte para o seguinte:

• Mensagens push multicast

• Tráfego multicast

• GDOI SNMP MIBs

• Protocolo e porta nas políticas enviadas pelo servidor. O membro do grupo honra apenas o endereço IP/sub-rede especificado na política.

• Várias políticas não emparelhadas para a mesma chave de tráfego/SPI

• Sobreposição de IP local e remoto em instâncias de roteamento em uma configuração de gateway IKE

• Sobreposição de políticas de VPN de grupo que podem resultar em SAs incompatíveis

• IPv6 para controle e tráfego de dados

• Coexistência de IPsec e VPN de grupo no mesmo conjunto de serviços

• Coexistência de serviços como NAT e ALG no mesmo conjunto de serviços. NAT e VPN de grupo podem coexistir em diferentes conjuntos de serviços. No entanto, eles não podem coexistir no mesmo conjunto de serviços.

• A VPN Site a Site (S2S) e a VPN de ponto de extremidade dinâmico (DEP) podem coexistir com a VPN de Grupo em diferentes conjuntos de serviços. No entanto, eles não podem coexistir no mesmo conjunto de serviços.

• Vários grupos no mesmo conjunto de serviços

• Suporte a membros do grupo com GC/KS da Série SRX

• Suporte a membros do grupo com membro do grupo da Série SRX

• Hierarquia de chave lógica (LKH)

• Reinicialização graciosa

• Alta disponibilidade

• ISSU unificado

• Suporte a PKI para autenticação