Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validação da origem do BGP

Entendendo a validação de origem para BGP

A validação de origem ajuda a evitar o anúncio involuntário das rotas. Às vezes, os administradores de rede anunciam erroneamente rotas para redes que não controlam. Você pode resolver esse problema de segurança configurando a validação de origem (também conhecida como roteamento seguro entre domínios). A validação de origem é um mecanismo pelo qual os anúncios de rota podem ser autenticados como originários de um sistema autônomo (AS) esperado. A validação de origem usa um ou mais servidores de cache de infraestrutura de chave pública (RPKI) para realizar autenticação para prefixos BGP especificados. Para autenticar um prefixo, o roteador (speaker BGP) consulta o banco de dados de mapeamentos validados de prefixo para AS, que são baixados do servidor de cache e garante que o prefixo tenha se originado de um AS esperado.

Nota:

Quando você habilita a autenticação de RPKI, o Junos OS abre automaticamente a porta TCP 2222 sem qualquer aviso. Você pode aplicar um filtro para bloquear e proteger essa porta.

O Junos OS oferece suporte à validação de origem para prefixos IPv4 e IPv6.

Figura 1 mostra uma topologia de amostra.

Figura 1: Topologia de amostra para validação de origemTopologia de amostra para validação de origem

Padrões suportados

A implementação da validação de origem pelo Junos OS oferece suporte aos seguintes RFCs e rascunho:

  • RFC 6810, a infraestrutura de chave pública de recursos (RPKI) para o protocolo de roteador

  • RFC 6811, validação de origem de prefixo BGP

  • Rascunho da Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (suporte parcial)

    A comunidade estendida (estado de validação de origem) é apoiada na política de roteamento do Junos OS. A mudança especificada no procedimento de seleção de rota não é suportada.

Como funciona a validação da origem

O RPKI e a validação de origem utilizam certificados X.509 com extensões especificadas nas extensões RFC 3779, X.509 para endereços IP e identificadores AS.

O RPKI consiste em uma coleção distribuída de informações. Cada Autoridade de Certificação publica seus certificados de entidade final (EE), listas de revogação de certificados (CRLs) e objetos assinados em um local específico. Todos esses repositórios formam um conjunto completo de informações que está disponível para todos os servidores de cache RPKI.

Cada servidor de cache RPKI mantém um cache local de toda a coleta distribuída de repositórios sincronizando regularmente cada elemento no cache local em relação ao ponto de publicação original do repositório.

No roteador, as entradas de banco de dados são formatadas como registros de validação de rota (RV). Um registro de RV é um triplo (prefixo, comprimento máximo, origem AS). Ele corresponde a qualquer rota cujo prefixo corresponde ao prefixo de RV, cujo comprimento de prefixo não excede o comprimento máximo dado no registro de RV, e cuja origem AS é igual à origem COMO dada no registro de RV.

Um registro de RV é uma versão simplificada de uma autorização de origem de rota (ROA). Um ROA é um objeto assinado digitalmente que fornece um meio de verificar se um titular de bloco de endereço IP autorizou um AS a originar rotas para um ou mais prefixos dentro do bloco de endereços. Os ROAs não são usados diretamente na validação de rota. O servidor de cache exporta uma versão simplificada do ROA para o roteador como um registro de RV.

O valor máximo de comprimento deve ser maior ou igual ao comprimento do prefixo autorizado e menor do que ou igual ao comprimento (em bits) de um endereço IP na família de endereços (32 para IPv4 e 128 para IPv6). O comprimento máximo define o prefixo de endereço IP que o AS está autorizado a anunciar.

Por exemplo, se o prefixo de endereço IP for de 200,4,66/24, e o comprimento máximo for de 26, o AS está autorizado a anunciar 200,4,66,0/24, 200,4,66,0/25, 200,4,66,128/25, 200,4,66,0/26, 200,4,66,64/26, 200,4,66,128/26 e 200,46,192/26. Quando o comprimento máximo não estiver presente, o AS só está autorizado a anunciar exatamente o prefixo especificado no RV.

Como outro exemplo, um RV pode conter o prefixo 200.4.66/24 com um comprimento máximo de 26, bem como o prefixo 200.4.66.0/28 com um comprimento máximo de 28. Este RV autorizaria o AS a anunciar qualquer prefixo a partir de 200,4,66 com comprimento de pelo menos 24 e não superior a 26, bem como o prefixo específico 200.4.66.0/28.

A origem de uma rota é representada pelo número de AS mais correto no atributo AS_PATH. A validação de origem opera comparando a origem AS em uma atualização de roteamento com o AS de origem autorizado publicado em registros de RV.

A segurança fornecida pela validação de origem por si só é conhecida por ser fraca contra um invasor determinado porque não há proteção contra tal invasor spoofing do AS fonte. Dito isto, a validação de origem oferece proteção útil contra anúncios acidentais.

Embora a validação de origem possa ser implementada tendo cada roteador participando diretamente do RPKI, isso é visto como muito intensivo em recursos (porque muitas operações de criptografia de chave pública são necessárias para validar os dados RPKI) bem como operacionalmente intensivas para configurar e manter uma configuração RPKI em cada roteador. Por esse motivo, um servidor de cache RPKI separado realiza validações de chave pública e gera um banco de dados validado de mapeamentos de prefixo para AS. O banco de dados validado é baixado em um roteador cliente por uma conexão TCP segura. Assim, o roteador requer poucas informações sobre a infraestrutura RPKI e não tem requisitos de criptografia de chave pública, além da senha de transporte criptografada. Posteriormente, o roteador usa os dados baixados para validar as atualizações de rota recebidas.

Ao configurar sessões de servidor, você pode agrupar as sessões e configurar parâmetros de sessão para cada sessão no grupo. O roteador tenta periodicamente configurar um número máximo configurável de conexões para servidores de cache. Se a configuração da conexão falhar, uma nova tentativa de conexão é feita periodicamente.

Enquanto isso, após a política de importação de validação ser aplicada à sessão BGP, a validação de rota é realizada independentemente do estado de sessão de cache (para cima ou para baixo) e banco de dados de RV (vazio ou não). Se o banco de dados de RV estiver vazio ou nenhuma das sessões de servidor de cache estiver ativada, o estado de validação para cada rota será definido como desconhecido, porque não existe registro de RV para avaliar um prefixo BGP recebido.

O período de tentativa de nova tentativa é configurável. Depois de se conectar com sucesso a um servidor de cache, o roteador consulta o número de série do banco de dados mais recente e solicita que o cache RPKI transmita todas as entradas de RV pertencentes a essa versão do banco de dados.

Cada mensagem de entrada reinicia um temporizador de linha de entrada para o servidor de cache RPKI. Depois que todas as atualizações são aprendidas, o roteador realiza verificações de liveliness periódicas com base em um intervalo configurável. Isso é feito enviando uma unidade de dados de protocolo de consulta de série (PDU) com o mesmo número de série que o servidor de cache relatou em sua mais recente PDU de notificação. O servidor de cache responde com zero ou mais atualizações e uma PDU de fim de dados (EOD), que também atualiza o estado de livelines do servidor de cache e reinicia um temporizador de vida recorde.

Quando um prefixo é recebido de um peer BGP externo (EBGP), ele é analisado por uma política de importação e marcado como válido, inválido, desconhecido ou não verificado:

  • Válido — indica que o prefixo e o par AS são encontrados no banco de dados.

  • Inválido — indica que o prefixo foi encontrado, mas o AS correspondente recebido do peer EBGP não é o AS que aparece no banco de dados, ou o comprimento do prefixo na mensagem de atualização BGP é mais longo do que o comprimento máximo permitido no banco de dados.

  • Desconhecido — indica que o prefixo não está entre os prefixos ou intervalos de prefixo no banco de dados.

  • Não verificado — indica que a origem do prefixo não está verificada no banco de dados. Isso porque o banco de dados foi preenchido e a validação não é exigida na política de importação do BGP, embora a validação de origem esteja habilitada ou a validação de origem não esteja habilitada para os pares BGP.

Se houver alguma correspondência em potencial para a rota no banco de dados de validação, a rota precisa combinar com uma delas para ser válida. Caso contrário, é inválido. Qualquer correspondência é adequada para tornar a rota válida. Não precisa ser o melhor jogo. Somente se não houver correspondências potenciais é a rota considerada desconhecida. Para obter mais informações sobre a lógica do banco de dados de mapeamento prefixo para AS, consulte a Seção 2 do rascunho da Internet draft-ietf-sidr-pfx-validado-01, validação de origem de prefixo BGP.

Nota:

A validação de RPKI está disponível apenas na instância primária. Se você configurar a validação de RPKI para uma instância de roteamento, a validação de RPKI falhará com a seguinte mensagem de erro.RV instance is not running

Interação do BGP com o banco de dados de validação de rotas

O banco de dados de validação de rota (RV) contém uma coleção de registros de RV que o roteador baixa do servidor de cache RPKI. Após o banco de dados de RV ser preenchido com registros de RV, o banco de dados de RV verifica a tabela de roteamento RIB-Local para determinar se há algum prefixo no RIB-Local que possa ser afetado pelos registros de RV no banco de dados. (RIB-Local contém as rotas IPv4 e IPv6 mostradas na saída do comando.)show route protocol bgp

Esse processo desencadeia uma reavaliação bgp de políticas de importação BGP (não políticas de exportação).

Figura 2 mostra o processo.

Figura 2: Validação de rotas e BGP

As políticas de importação são aplicadas à RIB-In. Outra maneira de entender isso é que as políticas de importação são aplicadas às rotas que são mostradas na saída do comando, enquanto as políticas de exportação são aplicadas a rotas que são mostradas pelo comando.show route receive-protocol bgpshow route advertising-protocol bgp

Como mostrado , você usa políticas de roteamento de importação para controlar quais rotas o BGP coloca na tabela de roteamento e políticas de roteamento de exportação para controlar quais rotas o BGP anuncia da tabela de roteamento para seus vizinhos.Figura 3

Figura 3: Políticas de roteamento de importação e exportaçãoPolíticas de roteamento de importação e exportação

Quando você configura uma política de importação de validação de rota, a configuração da política usa uma condição de correspondência.validation-database Essa condição de correspondência desencadeia uma consulta no banco de dados de RV para o estado de validação de um prefixo em uma determinada instância de roteamento. A operação padrão é consultar o banco de dados de validação correspondente à instância de roteamento. Se nenhuma instância de validação de rota for encontrada, a instância primária será consultada.

Na política de importação BGP a seguir, a condição desencadeia uma pesquisa no banco de dados de RV do roteador.from validation-database Uma ação é tomada se o estado de validação for válido. A ação é aceitar a rota e definir a tabela de roteamento válida.validation-state

Atributo da comunidade para anunciar o estado de validação de RPKI aos vizinhos do IBGP

A validação de prefixo é feita apenas para atualizações externas do BGP (EBGP). Dentro de um AS, é provável que você não queira ter uma sessão de RPKI em execução em todos os roteadores BGP (IBGP) internos. Em vez disso, você precisa de uma maneira de transportar o estado de validação por toda a malha do IBGP para que todos os palestrantes do IBGP tenham informações consistentes. Isso é feito transportando o estado de validação em uma comunidade estendida não transitiva. O atributo da comunidade anuncia e recebe o estado de validação de um prefixo entre os vizinhos do IBGP.

O Junos OS oferece suporte às seguintes comunidades estendidas bem conhecidas para validação de rotas:

  • validação de origem-estado válido

  • inválido em estado de validação de origem

  • origem-validação-estado desconhecido

A política de importação BGP da amostra a seguir está configurada no roteador que tem uma sessão com um servidor RPKI.

Roteador com sessão RPKI

A política de importação BGP da amostra a seguir está configurada em um roteador peer IBGP que não tem uma sessão com um servidor RPKI.

Roteador de peer IBGP sem sessão RPKI

Validação ininterrupta de roteamento ativo e origem

Quando você configura a validação de origem em um roteador que tem mecanismos de roteamento duplos e o roteamento ativo ininterrupto é habilitado, tanto os mecanismos primários quanto os mecanismos de roteamento de espera têm uma cópia do banco de dados de RV. Esses dois bancos de dados de RV permanecem sincronizados entre si.

O roteador não mantém duas sessões idênticas com o servidor RPKI. O protocolo RPKI-RTR é executado apenas no mecanismo de roteamento primário. No mecanismo de roteamento de espera, a sessão do servidor de cache RPKI está sempre baixa.

O banco de dados de RV é mantido ativamente pelo mecanismo de roteamento primário por meio de sua sessão com o servidor RPKI. Este banco de dados é replicado no mecanismo de roteamento em standby. Embora a sessão esteja no standby Routing Engine, o banco de dados de RV replicado contém registros de RV. Quando o mecanismo de roteamento de espera se transforma e se torna o mecanismo de roteamento principal, ele já tem um banco de dados de RV totalmente preenchido.

Para visualizar o conteúdo dos dois bancos de dados, use e comandos.show validation databaseshow validation replication database

Marcando um intervalo de prefixo como nunca permitido

O modelo de validação de rota tem uma grande deficiência: Ele só fornece atualizações positivas. Ele pode declarar qual AS é o proprietário legítimo de um prefixo. No entanto, ela não pode transmitir explicitamente uma atualização negativa, como em: Este prefixo nunca foi originado por um determinado AS. Essa funcionalidade pode ser fornecida até certo ponto usando uma solução alternativa AS 0.

A implementação do Junos OS não tenta restringir suas entradas do cache. Por exemplo, um registro de RV com o as 0 de origem é instalado e combinado como qualquer outro. Isso permite uma solução alternativa para marcar um intervalo de prefixo, pois o AS 0 não é um AS válido. O AS no registro de RV nunca corresponde ao AS recebido do peer EBGP. Assim, qualquer prefixo correspondente é marcado como inválido.

Caso de uso e validação do benefício de origem para BGP

Se um administrador de um sistema autônomo (AS) começar a anunciar toda ou parte da rede atribuída de outra empresa, o BGP não tem um método integrado para reconhecer o erro e responder de uma maneira que evitaria interrupções de serviço.

Suponha, por exemplo, que um administrador em uma rede de clientes anuncie erroneamente uma rota (digamos 10.65.153.0/24) direcionando o tráfego para o provedor de serviços do cliente AS 1. Esta rota /24 é uma rota mais específica do que a usada pelo provedor de conteúdo real (10.65.152.0/22) que direciona o tráfego para AS 2. Devido à maneira como os roteadores funcionam, a maioria dos roteadores seleciona a rota mais específica e envia tráfego para AS 1 em vez de AS 2.

O prefixo seqüestrado é visto amplamente em toda a Internet à medida que os roteadores de trânsito propagam as informações de caminho atualizadas. As rotas inválidas podem ser distribuídas amplamente pela Internet, pois os roteadores da zona livre padrão (DFZ) transportam a rota seqüestrada. Eventualmente, o caminho de AS correto é restaurar para os pares BGP, mas, enquanto isso, espera-se que as interrupções de serviços sejam esperadas.

Como o BGP depende de um modelo de confiança transitivo, a validação entre o cliente e o provedor é importante. No exemplo acima, o provedor de serviços AS 1 não validou o anúncio defeituoso para 10,65.153,0/24. Ao aceitar este anúncio e readvertê-lo para seus pares e provedores, o AS 1 estava propagando o caminho errado. Os roteadores que receberam essa rota do AS 1 a selecionaram porque era uma rota mais específica. O provedor de conteúdo real estava anunciando 10.65.152.0/22 antes do erro ocorrer. O /24 era um anúncio menor (e mais específico). De acordo com o processo habitual de seleção de rotas BGP, o /24 foi então escolhido, completando efetivamente o seqüestro.

Mesmo com a detecção rápida e a reação do provedor de conteúdo e a cooperação com outros provedores, o serviço para seu prefixo pode ser interrompido por muitos minutos até várias horas. A duração exata da interrupção depende do seu ponto de vista na Internet. Quando esses tipos de eventos ocorrem, há um interesse renovado em soluções para essa vulnerabilidade. O BGP é fundamental para as relações com provedores e não desaparecerá tão cedo. Este exemplo demonstra uma solução que usa validação de origem. Essa solução conta com extensões criptográficas para BGP e um modelo de servidor de cliente distribuído que evita o excesso de limites de CPUs do roteador.

A validação de origem ajuda a superar a vulnerabilidade da confiança transitiva, permitindo que um provedor limite os anúncios que aceita de um cliente. A mecânica envolve a comunicação de políticas de roteamento com base em um atributo estendido da comunidade BGP.

Exemplo: Configuração da validação de origem para BGP

Este exemplo mostra como configurar a validação de origem entre os pares BGP, garantindo que os anúncios de rota recebidos sejam enviados (originados) do sistema autônomo esperado (AS). Se o AS de origem for validado, uma política pode especificar que os prefixos são anunciados por sua vez.

Requisitos

Este exemplo tem os seguintes requisitos de hardware e software:

  • Servidor de cache de infraestrutura de chave pública de recursos (RPKI), usando software de terceiros para autenticar prefixos BGP.

  • Junos OS Release 12.2 ou posterior no dispositivo de roteamento que se comunica com o servidor de cache por uma conexão TCP.

Visão geral

Às vezes, as rotas são anunciadas involuntariamente devido a erro do operador. Para evitar esse problema de segurança, você pode configurar o BGP para validar o AS de origem e rejeitar esses anúncios inválidos. Esse recurso usa um servidor de cache para autenticar prefixos ou intervalos de prefixo.

As seguintes declarações de configuração permitem a validação AS de origem:

Este exemplo usa configurações padrão para os parâmetros de validação.

A maioria das declarações de configuração disponíveis são opcionais. As configurações necessárias são as seguintes:

O nível de hierarquia permite configurar registros estáticos em um dispositivo de roteamento, substituindo assim os registros recebidos de um servidor de cache RPKI.[edit routing-options validation static]

Por exemplo:

Você pode configurar uma política de roteamento que opera com base no estado de validação de um prefixo de rota. Você pode usar um atributo da comunidade para anunciar e receber o estado de validação de um prefixo entre os pares BGP (EBGP) externos e BGP interno (IBGP). Usar uma política de roteamento pode ser mais conveniente em alguns roteadores do que configurar uma sessão com um servidor RPKI. Este exemplo demonstra o uso do atributo da comunidade de estado de validação entre os pares do IBGP.

Figura 4 mostra a topologia da amostra.

Figura 4: Topologia para validação de origemTopologia para validação de origem

Neste exemplo, o Dispositivo R0 tem uma conexão IBGP com o dispositivo R1 e uma conexão EBGP com o dispositivo R2. O R0 do dispositivo recebe registros de validação de rota (RV) do servidor de cache usando o protocolo definido no rascunho da Internet draft-ietf-sidr-rpki-rtr-19, O Protocolo RPKI/Roteador para enviar os registros de RV. O protocolo RPKI-Router ultrapassa o TCP. Os registros de RV são usados pelo Dispositivo R0 para construir um banco de dados local de RV. No Dispositivo R1, o estado de validação é definido com base na comunidade BGP chamada estado de validação, que é recebida com a rota.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de hierarquia.[edit]

Dispositivo R0

Dispositivo R1

Dispositivo R2

Configuração do dispositivo R0

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar o dispositivo R0:

  1. Configure as interfaces.

  2. Configure BGP.

    Aplique a política de exportação para que as rotas diretas sejam exportadas da tabela de roteamento para o BGP.send-direct

    Aplique a política de importação para definir os atributos de estado de validação e da comunidade BGP para todas as rotas importadas (ou recebidas) dos pares EBGP do Dispositivo R0.validation

    Configure uma sessão do IBGP com o Dispositivo R1. Configure uma sessão de EBGP com o dispositivo R2.

  3. Configure o OSPF (ou outro protocolo de gateway interior [IGP]) na interface que enfrenta o peer IBGP e na interface de loopback.

    Nota:

    Se você usar o endereço da interface de loopback na declaração do IBGP , você deve habilitar um IGP na interface de loopback.neighbor Caso contrário, a sessão do IBGP não está estabelecida.

  4. Configure a política de roteamento que exporta rotas diretas da tabela de roteamento para o BGP.

  5. Configure a política de roteamento que especifica atributos a serem modificados com base no estado de validação de cada rota BGP.

  6. Configure a sessão com o servidor de cache RPKI.

  7. Configure o número do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfacesshow protocolsshow policy-optionsshow routing-options Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no modo de configuração.commit

Configuração do dispositivo R1

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar o dispositivo R1:

  1. Configure as interfaces.

  2. Configure BGP.

    Aplique a política de importação para definir os atributos do estado de validação e da comunidade BGP para todas as rotas recebidas dos pares do IBGP do Dispositivo R1.validation-ibgp

    Configure uma sessão do IBGP com o Dispositivo R0.

  3. Configure OSPF.

  4. Configure a política de roteamento que especifica atributos a serem modificados com base no atributo da comunidade BGP de estado de validação das rotas BGP recebidas do Dispositivo R0.

  5. Configure o número do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfacesshow protocolsshow policy-optionsshow routing-options Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no modo de configuração.commit

Configuração do dispositivo R2

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar o dispositivo R2:

  1. Configure as interfaces.

    Vários endereços estão configurados na interface de loopback para servir como rotas para fins de demonstração.

  2. Configure BGP.

  3. Configure a política de roteamento.

  4. Configure o número do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfacesshow protocolsshow policy-optionsshow routing-options Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no modo de configuração.commit

Verificação

Confirme se a configuração está funcionando corretamente.

Verificando se os atributos modificados são exibidos nas tabelas de roteamento

Propósito

Verifique se as rotas BGP no Dispositivo R0 e no Dispositivo R1 têm os estados de validação esperados e as preferências locais esperadas.

Ação

A partir do modo operacional, entre no comando.show route

Significado

As rotas têm os estados de validação esperados e os valores de preferência local, com base em informações recebidas do servidor de cache RPKI.

Usando operações de rastreamento

Propósito

Configure operações de rastreamento para validação de origem e monitore os resultados de uma rota recém-anunciada.

Ação
  • No dispositivo R0, configure o rastreamento.

  • No dispositivo R2, adicione uma rota adicionando outro endereço na interface de loopback.

  • No dispositivo R0, verifique o arquivo de rastreamento.

Significado

A validação da rota está operando como esperado.

Exibindo informações de validação

Propósito

Execute os vários comandos de validação.

Ação