Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

validação BGP origem

Entender a validação de origem para BGP

A validação de origem ajuda a evitar o anúncio não intencional de rotas. Às vezes, os administradores de rede anunciam 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 entre domínios seguro). A validação de origem é um mecanismo pelo qual os anúncios de roteamento podem ser autenticados como origem 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 dados especificados. Para autenticar um prefixo, o roteador (BGP speaker) 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 origem em um AS esperado.

Nota:

Ao habilitar a autenticação RPKI, o Junos OS abre automaticamente a porta TCP 2222 sem aviso prévio. Você pode aplicar um filtro para bloquear e proteger essa porta.

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

Figura 1 mostra uma topologia amostral.

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

Padrões suportados

A validação de validação de origem da implementação do Junos OS dá suporte aos seguintes RFCs e um rascunho:

  • RFC 6810, RpKI (Resource Public Key Infrastructure, Infraestrutura de Chave Pública de Recursos) para Protocolo de Roteador

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

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

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

Como funciona a validação de origem

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

O RPKI consiste em uma coleta distribuída de informações. Cada Autoridade de Certificação publica seus certificados de entidade final (EE), listas de revocação de certificados (CRLs) e objetos assinados em um local específico. Todos esses repositórios formam um conjunto completo de informações disponíveis para cada servidor de cache RPKI.

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

No roteador, as entradas do 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 bate com qualquer rota cujo prefixo bate com o prefixo RV, cujo comprimento de prefixo não exceda o comprimento máximo dado no registro de RV, e cuja origem AS é igual à origem AS dada no registro de RV.

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

O valor de comprimento máximo deve ser maior ou igual ao comprimento do prefixo autorizado e inferior 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 200.4.66/24, e o comprimento máximo for 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.4.66.192/26. Quando o comprimento máximo não está 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. Esse RV autorizaria o AS a anunciar qualquer prefixo a partir de 200.4.66 com um comprimento de pelo menos 24 e não maior que 26, bem como o prefixo específico 200.4.66.0/28.

A origem de uma rota é representada pelo número AS mais certo do atributo AS_PATH direita. A validação de origem opera ao comparar a origem as em uma atualização de roteamento com o AS de origem autorizado publicado nos registros de RV.

Sabe-se que a segurança fornecida pela validação de origem é fraca contra um determinado invasor, porque não existe proteção contra esse invasor que esofe a origem. Dito isso, a validação de origem fornece 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 de recursos (porque muitas operações de criptografia de chave pública são necessárias para validar os dados RPKI), bem como intensas operacionalmente para configurar e manter uma configuração RPKI em cada roteador. Por isso, um servidor de cache RPKI separado realiza validações de chaves públicas e gera um banco de dados validado de mapeamentos de prefixo para AS. O banco de dados validado é baixado para um roteador cliente por meio de uma conexão TCP segura. Assim, o roteador requer pouca informação sobre a infraestrutura RPKI e não tem requisitos de criptografia de chave pública, além da senha de transporte criptografado. Posteriormente, o roteador usa os dados baixados para validar 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 do grupo. Periodicamente, o roteador tenta configurar um número máximo de conexões configurável para servidores de cache. Se a configuração da conexão falha, uma nova tentativa de conexão é feita periodicamente.

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

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

Cada mensagem de entrada redefine um temporizador de beleza para o servidor de cache RPKI. Depois que todas as atualizações são aprendidas, o roteador realiza verificações periódicas de vivacência com base em um intervalo configurável. Isso é feito enviando uma unidade de dados do protocolo de consulta serial (PDU) com o mesmo número de série que o servidor de cache relatou em sua PDU de notificação mais recente. 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 vivacência do servidor de cache e redefine um temporizador de vida útil recorde.

Quando um prefixo é recebido de um peer de BGP externo (EBGP), ele é investigado 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 estão no banco de dados.

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

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

  • Não verificado — indica que a origem do prefixo não é verificada no banco de dados. Isso ocorre porque o banco de dados foi preenchido e a validação não é chamada na política de importação BGP, embora a validação de origem seja habilitada ou a validação de origem não seja habilitada para BGP peers.

Caso haja alguma combinação 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, ele é inválido. Qualquer combinação é adequada para tornar a rota válida. Não precisa ser uma combinação melhor. Somente se não houver combinações potenciais é que a rota seja 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 draft da Internet-ietf-sidr-pfx-validate-01, validação de origem de BGP Prefixo.

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 do RPKI falha com a seguinte mensagem de RV instance is not running erro.

BGP interação com o banco de dados de validação de rotas

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

Esse processo aciona uma BGP reavaliação das políticas de BGP de importação (não as políticas de exportação).

Figura 2 mostra o processo.

Figura 2: BGP e validação de rotas

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

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

Figura 3: Importação e exportação de políticas de roteamentoImportação e exportação de políticas de roteamento

Ao configurar uma política de importação de validação de rota, a configuração de política usa uma validation-database condição de combinação. Essa condição de combinação aciona uma consulta no banco de dados de RV para consultar 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 que combina a instância do roteamento. Se nenhuma instância de validação de rota for encontrada, a instância primária será consultada.

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

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

A validação de prefixo é feita apenas para atualizações BGP externos (EBGP). Dentro de um AS, é provável que você não queira ter uma sessão RPKI em execução em todos os roteadores internos de BGP (IBGP). Em vez disso, você precisa de uma maneira de levar o estado de validação pela malha IBGP para que todos os alto-falantes IBGP tenham informações consistentes. Isso é realizado 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 IBGP.

O Junos OS aceita as seguintes comunidades estendidas conhecidas para validação de rotas:

  • validação de origem

  • origem-validação estado inválido

  • origem-validação estado-desconhecido

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

Sessão Roteador com RPKI

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

Roteador de peer IBGP sem sessão de RPKI

Validação de origem e roteamento ativo sem parar

Quando você configura a validação de origem em um roteador que tenha dois Mecanismos de Roteamento e roteamento ativo sem escalas, ele fica habilitado, tanto o principal como os Mecanismos de Roteamento em espera têm uma cópia do banco de dados de RV. Esses dois bancos de dados de RV continuam sincronizados entre si.

O roteador não mantém duas sessões idênticas com o servidor RPKI. O protocolo RPKI-RTR é executado apenas na base Mecanismo de Roteamento primária. Na sessão de Mecanismo de Roteamento de espera, a sessão do servidor de cache RPKI está sempre inovada.

O banco de dados de RV é mantido ativamente pela rede Mecanismo de Roteamento durante sua sessão com o servidor RPKI. Esse banco de dados é replicado no sistema de Mecanismo de Roteamento. Embora a sessão fique em standby Mecanismo de Roteamento, o banco de dados RV replicado contém registros de RV. Quando o sistema de Mecanismo de Roteamento comuta e se torna o principal Mecanismo de Roteamento, ele já tem um banco de dados RV totalmente preenchido.

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

Marcando um intervalo de prefixo como nunca permitido

O modelo de validação de rotas tem uma grande deficiência: Ele só fornece atualizações positivas. Ele pode declarar qual AS é o legítimo proprietário de um prefixo. No entanto, ela não pode transmitir explicitamente uma atualização negativa, como em: Esse prefixo nunca foi originado por um dado 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 origem AS 0 é instalado e é igualmente igual a qualquer outro. Isso permite que uma solução alternativa marque um intervalo de prefixo como nunca autorizado a ser anunciado, porque o AS 0 não é um AS válido. O AS no registro de RV nunca bate com o AS recebido do peer EBGP. Assim, qualquer prefixo correspondente está inválido.

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

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

Imagine, por exemplo, que um administrador de uma rede de clientes anuncia uma rota erroneamente (digamos 10.65.153.0/24) direcionando o tráfego ao provedor de serviços do cliente AS 1. Essa 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 escolhe a rota mais específica e envia tráfego para AS 1 em vez de AS 2.

O prefixo seqüestrado é visto amplamente na Internet à medida que roteadores de trânsito propagam as informações de caminho atualizadas. As rotas inválidas podem ser distribuídas amplamente pela Internet conforme os roteadores na zona livre padrão (DFZ) transportam a rota seqüestrada. No fim das contas, o caminho de AS correto é BGP seus colegas, mas, enquanto isso, é esperado interrupções de serviço.

Como BGP confia em um modelo de confiança transitivo, a validação entre cliente e provedor é importante. No exemplo acima, o provedor de serviços AS 1 não validou o anúncio com defeito para 10.65.153.0/24. Ao aceitar esse anúncio e readverti-lo para seus colegas e provedores, o AS 1 estava propagando o caminho errado. Os roteadores que receberam essa rota do AS 1 a selecionaram por ser uma rota mais específica. O provedor de conteúdo real estava anunciando 10.65.152.0/22 antes do erro ocorrer. O /24 foi um anúncio menor (e mais específico). De acordo com o processo BGP de seleção de roteamento, o /24 foi então escolhido, concluindo efetivamente o seqüestro.

Mesmo com a rápida detecção e reação do provedor de conteúdo e a cooperação com outros provedores, o serviço por seu prefixo pode ser interrompido por muitos minutos até várias horas. A duração exata da paralisação depende do seu ponto de vista na Internet. Quando ocorrem esses tipos de eventos, há um interesse renovado por soluções para essa vulnerabilidade. BGP é fundamental para as relações com provedores e não vai embora tão cedo. Este exemplo demonstra uma solução que usa validação de origem. Essa solução depende de extensões criptográficas para BGP e um modelo de servidor-cliente distribuído que evita sobrecarregamento 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. Os mecanismos envolvem a comunicação de políticas de roteamento com base em um atributo BGP comunidade estendida.

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

Este exemplo mostra como configurar a validação de origem entre BGP peers, garantindo que os anúncios de roteamento 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, por sua vez, anunciados.

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 BGP prefixos.

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

Visão geral

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

As declarações de configuração a seguir permitem a validação de 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 é opcional. As configurações necessárias são as seguinte:

O nível da hierarquia permite configurar registros estáticos em um dispositivo de roteamento, sobreposição de registros [edit routing-options validation static] recebidos de um servidor de cache RPKI.

Por exemplo:

Você pode configurar uma política de roteamento que opera com base no estado de validação de um prefixo de roteamento. Você pode usar um atributo da comunidade para anunciar e receber o estado de validação de um prefixo entre BGP externo (EBGP) e peers de BGP internos (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 comunidade de estado de validação entre os peers IBGP.

Figura 4 mostra a topologia amostral.

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 dispositivo R0 recebe registros de validação de rota (RV) do servidor de cache usando o protocolo definido na proposta de Internet draft-ietf-sidr-rpki-rtr-19, o protocolo RPKI/Roteador para enviar os registros de RV. O protocolo RPKI-Roteador é executado por TCP. Os registros de RV são usados pelo dispositivo R0 para criar um banco de dados de RV local. 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 CLI

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

Dispositivo R0

Dispositivo R1

Dispositivo R2

Configurando o dispositivo R0

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o dispositivo R0:

  1. Configure as interfaces.

  2. Configure BGP.

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

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

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

  3. Configure 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 de interface de loopback na instrução IBGP, você deve habilitar uma IGP neighbor na interface de loopback. 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 BGP.

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

  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 show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Configurando o dispositivo R1

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o dispositivo R1:

  1. Configure as interfaces.

  2. Configure BGP.

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

    Configure uma sessão IBGP com o dispositivo R0.

  3. Configure OSPF.

  4. Configure a política de roteamento que especifica os atributos a serem modificados com base no atributo community-state de BGP de validação das BGP rotas 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 show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Configurando o dispositivo R2

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

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 show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

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

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

Propósito

Verificar se as BGP do dispositivo R0 e do dispositivo R1 têm os estados de validação esperados e as preferências locais esperadas.

Ação

Do modo operacional, insira o show route comando.

Significado

As rotas têm os estados de validação esperados e os valores de preferência local, com base nas 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 nova rota 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, consulte o arquivo de rastreamento.

Significado

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

Exibindo informações de validação

Propósito

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

Ação