Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validação de origem BGP

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 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 anúncios de roteamento 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 (alto-falante 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 RPKI, o Junos OS abre a porta TCP 2222 automaticamente 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 amostral.

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 do Junos OS oferece suporte aos seguintes RFCs e rascunho:

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

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

  • Draft 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 de origem

O RPKI e a validação de origem usam certificados X.509 com extensões especificadas em 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 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 corresponde a qualquer rota cujo prefixo corresponda ao prefixo RV, cujo comprimento de prefixo não excede o comprimento máximo dado no registro de RV, e cuja origem AS iguala o AS de origem dado 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 rotas. 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 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 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 um 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 mais certo no atributo AS_PATH. A validação de origem opera comparando o AS de origem em uma atualização de roteamento com o AS de origem autorizado publicado em registros de RV.

A segurança fornecida apenas pela validação de origem é conhecida por ser fraca contra um invasor determinado porque não há proteção contra tal invasor falsificando o AS de 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 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 isso, 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 de 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 do grupo. O roteador tenta periodicamente configurar um número máximo configurável de conexões com 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 do banco de dados de RV (vazio ou não). Se o banco de dados de RV estiver vazio ou nenhuma das sessões do servidor de cache estiver ativada, 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 tentativa de 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 redefine um temporizador de linha ao vivo para o servidor de cache RPKI. Após todas as atualizações serem aprendidas, o roteador realiza verificações periódicas de liveliness com base em um intervalo configurável. Isso é feito enviando uma unidade de dados de protocolo de consulta em série (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 livelines do servidor de cache e redefine um temporizador recorde de vida útil.

Quando um prefixo é recebido de um peer BGP externo (EBGP), ele é examinado 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 é encontrado, mas ou 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 é maior do que o comprimento máximo permitido no banco de dados.

  • Desconhecido — indica que o prefixo não está entre os prefixos ou faixas de prefixo no 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 é exigida na política de importação 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, ele é inválido. Qualquer correspondência é adequada para tornar a rota válida. Não precisa ser a melhor combinação. Somente se não houver correspondências em potencial é a rota considerada desconhecida. Para obter mais informações sobre a lógica do banco de dados de mapeamento prefixo-to-AS, consulte a Seção 2 do draft da Internet draft-ietf-sidr-pfx-validate-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 RPKI para uma instância de roteamento, a validação RPKI falhará com a seguinte mensagem RV instance is not runningde erro.

Interação BGP 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. 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 show route protocol bgp comando.)

Esse processo desencadeia uma reavaliação BGP das políticas de importação bgp (não 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 à 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 show route receive-protocol bgp políticas de exportação são aplicadas a rotas que são mostradas pelo show route advertising-protocol bgp comando.

Como mostrado Figura 3, 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: 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 rotas, a configuração da política usa uma validation-database condição de correspondência. 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 from validation-database condição desencadeia uma pesquisa no banco de dados de RV do roteador. Uma ação é tomada se o estado de validação for válido. A ação é aceitar a rota e definir a validation-state tabela de roteamento como válida.

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 bgp externas (EBGP). Dentro de um AS, é provável que você não queira ter uma sessão RPKI em execução em todos os roteadores BGP internos (IBGP). Em vez disso, você precisa de uma maneira de levar o estado de validação pela malha do IBGP para que todos os palestrantes do 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 vizinhos do IBGP.

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

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

  • origem validação-estado inválido

  • origem-validação-estado desconhecido

A política de importação BGP 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

Roteamento ativo sem parar e validação de 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 de roteamento 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 principal. 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 de espera. Embora a sessão esteja inserida no mecanismo de roteamento de espera, o banco de dados de RV replicado contém registros de RV. Quando o mecanismo de roteamento de espera muda e se torna o mecanismo de roteamento principal, ele já tem um banco de dados de RV totalmente preenchido.

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

Marcando uma faixa 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 proprietário legítimo de um prefixo. No entanto, ela não pode transmitir explicitamente uma atualização negativa, como em: Esse prefixo nunca foi originado por um determinado AS. Essa funcionalidade pode ser fornecida até certo ponto usando uma solução 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 combinado como qualquer outro. Isso permite uma solução alternativa para marcar uma faixa 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 de benefícios 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. Por causa da 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 sequestrado é 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) carregam a rota seqüestrada. Eventualmente, o caminho de AS correto é restaurado para os pares BGP, mas, enquanto isso, são esperadas interrupções de serviço.

Como o BGP depende de um modelo de confiança transitivo, a validação entre clientes e provedores é 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 foi um anúncio menor (e mais específico). De acordo com o processo de seleção de rotas BGP usual, o /24 foi então escolhido, efetivamente completando 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 paralisação depende do seu ponto de vista na Internet. Quando esses tipos de eventos ocorrem, há um interesse renovado por 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 das 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 mecânicos envolvem a comunicação de políticas de roteamento com base em um atributo estendido da comunidade BGP.

Example: 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 anúncios de rota recebidos sejam enviados (originados) do sistema autônomo (AS) esperado. 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 (RPKI), usando software de terceiros para autenticar prefixos BGP.

  • Junos OS Versão 12.2 ou posterior em execução 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 um erro do operador. Para evitar esse problema de segurança, você pode configurar o BGP para validar o AS originado e rejeitar esses anúncios inválidos. Esse recurso usa um servidor de cache para autenticar prefixos ou faixas de prefixo.

As seguintes declarações de configuração permitem a validação do 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 [edit routing-options validation static] 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.

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 origem Topologia 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 no draft da Internet draft-ietf-sidr-rpki-rtr-19, o protocolo RPKI/roteador para enviar os registros de RV. O protocolo RPKI-Router passa por cima do 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.

Cópia de

Configuração rápida da CLI

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

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

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

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

    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 interno [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 neighbor , você deve habilitar um IGP 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 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 nosshow interfaces, show protocolsshow policy-optionse show routing-options comandos. 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 commit modo de configuração.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar o dispositivo R1:

  1. Configure as interfaces.

  2. Configure BGP.

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

    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 nosshow interfaces, show protocolsshow policy-optionse show routing-options comandos. 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 commit modo de configuração.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

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 nosshow interfaces, show protocolsshow policy-optionse show routing-options comandos. 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 commit modo de configuração.

Verificação

Confirme que 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

Do modo operacional, entre no 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 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 de rotas está operando como esperado.

Exibindo informações de validação

Propósito

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

Ação