Home > IRR, RPKI, TCP/IP > Curso IRR: Aula complementar I – Espelhamento e segurança nos IRRs

Curso IRR: Aula complementar I – Espelhamento e segurança nos IRRs

18/04/2010 Leave a comment Go to comments

Atualização em 30/05/2010.
Atualização em 25/05/2010.
Atualização em 22/05/2010.

Como é feito o espelhamento

Os grandes provedores de backbone estão usando, sistematicamente, o IRR por razões de segurança, principalmente. Então, cada um estabeleceu um servidor IRR e muitos deles são espelhadas pelo RADB e, também, espelham o RADB. Mas, não necessariamente espelham TODOS os IRRs(1).

Cada IRR gera uma base (texto) populada por seus respectivos objetos. Geralmente leva o nome da base, como por exemplo, radb.db, level3.db, pegasus.db, etc. O whois e/ou ferramentas quando dirigidos a uma base específica, podem não encontrar um objeto pelo fato da base na qual ele foi inserido não existir naquele servidor. Se ela não existe é porque o servidor não espelha aquele IRR e nem armazena a base do IRR (via ftp, p. ex.).

As razões pelas quais nem todos os servidores IRR espelham ou mantem muitas das bases IRRs, a exemplo do RADB, não interessa no debate. Não merece o debate porque, nesse caso há ausência do princípio da cooperação (estima-se umas 60 bases descentralizadas de IRR). Cooperação contribui, significativamente, para Internet mais saudável. Para ilustrar a questão do espelhamento, o exemplo abaixo é interessante, além de exibir uma incoerência técnica:

     whois -m 187.49.0.0/20
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

     route:      187.49.0.0/20
     descr:      SCW Telecom - IPv4 CIDR block
     origin:     AS28138
     mnt-by:     MAINT-AS28138
     remarks:    Sat Apr 10 12:58:25 BRT 2010
     changed:    herbert@scw.net.br 20100410
     source:     PEGASUS

O whois da PCCW, na relação de IRRs é rr.ntt.net. O resultado da mesma consulta naquele servidor é:

     whois -h whois.pccwbtn.com 187.49.0.0/20    
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

Uma tentativa de consultar o AS28138, tem o resultado abaixo:

    whois -h rr.ntt.net AS28138
    %  No entries found for the selected source(s).

De onde pode-se concluir:

  1. O IRR da NTTCOM é espelhado pelo RADB.
  2. O IRR da NTTCOM não espelha o RADB.
  3. A NTTCOM registra seus objetos na sua própria base IRR e usa como valor do atributo source, o RADB.
  4. À incoerência técnica junte-se inconsitência da informação contida no atributo descr.

A Level3, por exemplo, não adota tal postura.

Entretanto há outras razões para tal comportamento: segurança e confiabilidade.

Segurança e confiabilidade do IRR

Recentemente, na lista Alumni (ex-alunos do curso de IPv6 do Nic.br – Alumni at ceptro dot br) houve um rápido debate sobre segurança nos IRRs. Tal debate envolvia RPKI (“Resource Public Key Infrastructure”), IRR e, por tabela, roteadores. Não iremos entrar no mérito das técnicas usadas pelo RPKI. Para quem se interessar em detalhes, os engenhos de pesquisas, são ótimos amigos. Um trabalho recente, sobre os padrões RPKI em desenvolvimento está em [7]. Também não iremos abordar nada relacionado a roteadores, mas há um sentimento de que o futuro deles passará por computações pervasiva e ubíqua. O conhecimento inicial para acompanhar as noções de criptografia para entender RPKI está vastamente exposto em [8] e [9].

Uma questão que tem sido lembrada mas, não tanto enfaticamente como deveria é a confiabilidade da base IRR. Por um lado, o fator custo da manutenção e, por outro, a razoável complexidade da linguagem de especificação (RPSL) das políticas de roteamento, que enfraquecem o espírito da atualização sistemática. Confiabilidade passa necessariamente por processos de aquisição de conhecimento e, naturalmente, orientação permanente uma vez que o cenário é muito dinâmico. Há um visível crescimento, em especial no Brasil, de novos ASes, com perspectiva de maior intensidade à medida que o IPv6 for aumentando a presença.

Desde uns dois anos atrás tem sido debatido e exposto(2) e, mais recentemente(3), a questão da segurança nas bases IRR. Randy Bush e outros colaboradores(3), têm insistido em um modelo interessante. Segurança muito mais atenta à confiabilidade do IRR e sua importância na direção de manter a Internet funcionando sem os problemas causados por erros de configuração, de originação (AS de origem) e na prevenção de ataques maliciosos. Tal proposta tem recebido aplausos e indicações de que os fundamentos que deram origem à RPSL, que especifica os objetos formadores da base IRR. Os seguintes pontos e motivações retiram eventuais dúvidas de interpretação da proposta:

  • Garantir a qualidade dos dados dos IRRs.
  • Criação de mecanismos formais de verificação da legitimidade dos objetos criados no IRR.
  • Criação de mecanismos formais para verificar as políticas de roteamento e respectivos anúncios.
  • Verificar a ORIGEM das políticas.
  • Verificar a corretude das políticas de roteamento criadas nos IRRs.
  • Administradores de ASes não compreendem ou, simplesmente, não querem usar IRRs.
  • A dependência pela disponibilidade da Internet tem crescido vertiginosamente.
  • Segurança dos sistemas de roteamento tem piorado, ao invés de melhorar(6).
  • A implementação completa do RPKI está disponível em “open source”(5).
  • Foco na validação dos anúncios de prefixos e não na proteção do transporte das conexões.
  • Toda e qualquer implementação do projeto deve ser “openSource”.

Finalmente, a figura abaixo, retirada de [6], indica que não se está pensando em substituir o IRR.

Figura 1: IP Address Allocation, Assignment, and IRR Conceptual Model(6).

Comentários finais

Os pequenos e médios provedores devem ficar atentos ao fato de que as propostas estão na mesa, com testes sendo feitos e disponíveis. A iniciativa é dos grandes provedores, principalmente os de backbone. Portanto, é preciso ficar atento e participar do debate, sob pena de haver consequências indesejáveis nas decisões que forem tomadas, à revelia e envolvendo interesses que podem afetar a futura infraestrutura da Internet. Mudanças que podem desagradar somente aos troianos. Os gregos querem, naturalmente, resolver o seu problema. E, rapidamente!

Eis algumas lembranças que devemos ter no processo do debate:

  • Evitar a descentralização de IRRs. Não se deve impor restrições na criação de uma base, mas não deveriam ser reconhecidas (digamos, homologadas), as bases criadas com características exclusivas.
  • Como as políticas de roteamento representam um componente importante para o funcionamento da Internet, não deveriam incorrer a custos. Em particular custos de certificação. Há um ponto de vista sensível sobre o debate: “uso do IRR custa dinheiro”. No LACNIC, aparente fato consumado está em [10]: “The objective is for all RIRs to be ready to start issuing
    certificates by no later than 01 January 2011.” . O que é bom, principalmente se os ASes puderem usar sem custo. Mas, os ASes, que possuem voz e voto no LACNIC devem se movimentar, principalmente, porque já existem custos sobre o ASN.
  • Evitar a centralização e controle excessivo sobre políticas de roteamento. O administrador de um AS está, em tese, preparado para gerenciar sua rede. Caso contrário devem ser estimulados a se preparar.
  • Evitar a classificação de um AS pelo sua dimensão. Para a Internet, quanto mais for descentralizada a competência e administração da rede, melhor. O modelo da governança atual da Internet deve ser mantido, a qualquer preço. Portanto, não se deve permitir que uma questão importante (como é o caso de políticas de roteamento), influencie negativamente, com reflexos em eventuais mudanças de gestão.
  • O Brasil, com um único IRR (aparentemente) é dono de uma rara oportunidade de desenvolver experiências de cooperação enfática, no momento em que a operação do Pegasus IRR ficará sob responsabilidade da Abranet.

Epílogo do segmento

Uma pergunta em palestra no GTER29(11), não foi bem respondida. A pergunta se referia a questões de segurança do IRR atual. Eis as respostas e comentários adicionais, fazendo uma referência à relação IRR x RPKI:

  1. A inclusão dos objetos mnter e person é, obrigatoriamente, feita pelo administrador da base IRR. Somente um descuido muito grande ou má fé poderiam permitir que tais objetos fossem manipulados por não administradores de ASes.
  2. A base principal do IRR, o RADB é sistematicamente atenta a abusos. Portanto, qualquer um pode enviar um e-mail para eles que serão imediatamente respondidos! É pura responsabilidade, por estar cuidando de uma comunidade sensível.
  3. O administrador de um AS pode manipular seus objetos sem nenhuma autenticação. Por pura opção pessoal. Nâo se tem notícias de que alguém faça isso. Até porque, dificilmente um administrador de IRR incluiria o objeto mntner, sem autenticação e, sem o objeto person.
  4. Há duas formas de autenticação: via senha criptografada e via PGP. Ambos são seguros dentro dos limites conhecidos. Na remota hipótese de sequestro de senhas ou chaves, a reação pode ser imediata. O telefone do INOC está ai com esse objetivo, por exemplo.
  5. O RPKI é semelhante ao DNSSEC. No final, seu objetivo é estabelecer a cadeia de confiança. A cadeia de confiança é mais problemática nos processos automáticos que transmitem informações em redes inseguras (aka Internet), no caso do IRR, unidirecional.
  6. Deveriam haver estudos na direção de identificar como será o comportamento dos administores de ASes e as propostas dos fabricantes que estão trabalhando em diversas direções. A tendência vem mostrando que técnicas associadas a SOA podem se tornar vitoriosas. Nesse caso, pensa-se em outras técnicas e tecnologias que não o RPKI.
  7. O RPKI sobre o IRR é um paradigma, no conceito de Kuhn(12). A origem da proposta de RPKI no IRR, provavelmente veio de uma recomendação no item 8 (último parágrafo), da RFC2725(13), como alternativa no fortalecimento da autenticação mas, não única alternativa. Duas constatações que induzem à ampliação do debate com a participação insistente, dos administradores de ASes.

Itens relacionados:

Referências do segmento

1. List of Routing Registries. IRR. Disponível em: http://www.irr.net/docs/list.html. Acessado em: 18/05/2010.

2. Bush, R. e McPherson, D., Using the RPKI to Construct Validated IRR Data, em mensagem de McPherson, D., Policy Proposal: Minimum Allocation in the Caribbean Region , Disponível em: http://lists.arin.net/pipermail/arin-ppml/2008-May/010788.html. Acessado em 18/05/2010.

3. Bush, R., Austein, R. Austein, Bellovin, S., The RPKI \& Origin Validation, RIPE-60, Praga 03/05/2010. Disponível em: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The\_RPKI\_Origin\_Validation.pdf. Acessado em: 18/05/2010.

4. Bush, R., Austein, R., “The RPKI/Router Protocol”, Randy Bush, Rob Austein, 20-Feb-10. Disponível em http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-05. Acessado em: 18/05/2010.

5. Implementação em OpenSSL, do RPKI.

6. Steenbergen, R.,Volk, R., Kumari, W., Blunk, L. e McPherson, D., ISP Route Filtering: Responsibilities & Technical Challenges. Disponível em: http://www.nanog.org/meetings/nanog43/presentations/DanMcP_Route_Filter_Panel_N43.pdf. Acessado em 18/05/2010.

7. Patara, R., RPKI: Actualización sobre estándares en desarrollo, LACSEC, LACNIC XIII, 19/05/2010. Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/LACSEC/03-rpki-5seguridad.pdf. Acessado em: 19/05/2010.

8. Carlos, M. C., Sutil, J. M., Moecke, C. T., Kohler, J. G., Introdução a Infraestrutura de Chaves Públicas e Aplicações (ICPEDU), ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/icpedu?categoria=3&download=44f683a84163b3523afe57c2e008bc8c. Acessado em: 20/05/2010.

9. Moreira, E. Q., Foscarini, E. D., Silva Junior, G. C. da, Alixandrina, L. A. O., Vieira Neto, L. P. V., Federação CAFe: Implantação do Provedor de Identidade, ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/cafe?categoria=3&download=03afdbd66e7929b125f8597834fa83a4. Acessado em: 20/05/2010.

10. Rada, G., Sistema de Certificación de Recursos vBetaRPKI-LACNIC, LACNIC XIII, 19/05/2010, Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/tutoriales/rpkivbeta.pdf. Acessado em: 20/05/2010.

11. Braga, J., Políticas de roteamentos: como resolver a impossibilidade de implementação na tecnologia “hop-by-hop” e o futuro. Disponível em: ftp://ftp.registro.br/pub/gter/gter29/01-PoliticasRoteamento.pdf. Acessado em: 25/05/2010.

12. Kuhn, Thomas S., A Estrutura das Revoluções Científicas, Editora Perspectiva, São Paulo, 1996.

12. RFC2725, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

Categories: IRR, RPKI, TCP/IP