[GTER] Status Implementação RPKI NIR NIC.BR

Frederico A C Neves fneves at registro.br
Tue Jun 4 12:34:01 -03 2019


Douglas,

On Tue, Jun 04, 2019 at 10:01:31AM -0300, Douglas Fischer wrote:
> RE-RE-Ressucitando o tópico.
> 
> Observei que existe uma tendência dos RIRs/NIRs em disponibilizar as ROAs -
> Route Origin Authorization - em um formato IRR.
> 
> Isso está no Roadmap do Registro.BR?

O nosso plano de implementação ainda é o mesmo que foi apresentado na
última semana de infraestrutura. O objetivo é uma implementação segura
e robusta. O trabalho atual é no software que vai proporcionar a
arquitetura distribuída da tecnologia e a sua integração com os nossos
sistemas.

Todos que instalarem a CA RPKI Krill terão além de uma interface
web/cli para administração, também uma API para automação. Esta API é
um requisito inicial do projeto. Ela proporciona a arquitetura não
acoplada entre as interfaces de usuário e o backend da CA e é
justamente a nossa rota de integração para suportar o serviço.

Facilidades baseadas na disponibilização do serviço centralizado ou a
republicação das informações em outros formatos ainda não estão no
nosso horizonte de implementação.

Mas assim mesmo é importante observar o que está sendo feito nos
outros registros e irmos ajustando o que vai ser entregue no
futuro.

Por hora ainda não há o que se ajustar no plano original. Ainda
estamos por entregar o básico, mas com o investimento nesta
arquitetura vamos certamente chegar lá. Agradeço pelos seu entusiasmo
e comentários.

[]s
Fred

> Em qua, 15 de mai de 2019 às 22:49, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
> 
> > Re-Ressucitando o tópico!
> >
> > Nesse LACNIC que conheci uma:
> > "Interfaces mágicas desenvolvidas por alquimistas e videntes que
> > impossibilitem que cometamos equívocos grosseiros"
> >
> > O pessoal do Lacnic fez um trabalho incrível que faz o processo de criação
> > de ROAs via interface Web ser "quase" a prova de usuário.
> > Se entendi direito, ele envolve uma consulta na DFZ, e também alguma coisa
> > de sumarização para sugerir os ROAs de cada ASN.
> > Muito bom mesmo!
> >
> > Então meu primeiro pedido a equipe do NIC.br é:
> > ----------------------------------------------
> > Copiar do LACNIC essa ferramenta a prova de usuários de pouca capacidade.
> >
> >
> > Outra coisa que falei com várias pessoas lá no evento foi sobre a
> > necessidade de um mecanismo de inteiração automatizável(API).
> > Esse apontamento também foi feito(de maneira sutil) para o pessoal do
> > LACNIC pelo pessoal da Cloudflare na apresentação deles sobre Deploy de
> > RPKI.
> >
> > Uma coisa que foi quase que consenso foi sobre a possibilidade do
> > surgimento de regras do tipo "Libera tudo que to com saco de entrar aqui
> > denovo".
> >
> >
> > Então meu segundo pedido a equipe do NIC.BR é:
> > ----------------------------------------------
> > Para quando o modo hospedado for liberado, disponibilizar uma API para
> > operações de criação, renovação e revogação de ROAs.
> >
> >
> > Em qua, 21 de nov de 2018 às 14:46, Douglas Fischer <
> > fischerdouglas at gmail.com> escreveu:
> >
> >> Ressuscitando o tópico:
> >>
> >> Atualmente a região do LACNIC é a que mais tem registros de RPKi
> >> inconsistentes(+/- 1200).
> >> Pelo que li sobre ao assunto, muito disso decorreu de fatores como:
> >>  - No início havia uma falta de conhecimento/entendimento do publico alvo
> >> que fazia os cadastros dos registros.
> >>  - Também no início a ferramenta não ter "travas anti-dummies" tão bem
> >> elaboradas, permitiu que o usuário cadastrasse certas incoerências.
> >>    (Se fizermos o comparativo com certificados SSL, isso tipo de equívoco
> >> também é muito comum.)
> >>
> >>
> >> Com isso em mente, aproveito para perguntar à equipe do NIC.BR se
> >> existem ações para evitar esse tipo de problema.
> >>  - Treinamentos?
> >>  - Interfaces mágicas desenvolvidas por alquimistas e videntes que
> >> impossibilitem que cometamos equívocos grosseiros?
> >>
> >> Apesar de, se comparado com o resto do mundo, estarmos um tiquinho para
> >> trás, eu tenho dito que temos a vantagem de já ter toda a bagagem de erros
> >> dos outros RIRs/NIRs nessa questão e não cometê-los. Sinceramente acho isso
> >> uma vantagem BEM considerável.
> >>
> >> Agradeço a resposta desde já.
> >>
> >> Em sáb, 29 de set de 2018 às 21:19, Frederico A C Neves <
> >> fneves at registro.br> escreveu:
> >>
> >>> Douglas,
> >>>
> >>> On Sat, Sep 29, 2018 at 10:59:07AM -0300, Douglas Fischer wrote:
> >>> > Gostaria de saber da equipe do NIC.BR qual o status de implementação
> >>> da
> >>> > infraestrutura dos serviços de RPKI pelo NIC.BR, bem como uma
> >>> previsão de
> >>> > data para a disponibilização destes para os detentores de recursos
> >>> > numéricos do Brasil.
> >>>
> >>> Está em andamento.
> >>>
> >>> O plano atual prevê a disponibilização no final do primeiro semestre
> >>> de 2019 de uma nova interface para o sistema de IPs já com suporte a
> >>> DNSSEC e preparada para suportar os dois modos de operação do sistema
> >>> RPKI.
> >>>
> >>> Suporte a RPKI no modelo delegado, via protocolo UP/DOWN [1], será
> >>> disponibilizado no final do segundo segundo semestre de 2019.
> >>>
> >>> Em 2020 teremos disponível o serviço no modelo hospedado.
> >>>
> >>> A implementação é baseada no novo conjunto de ferramentas RPKI [2]
> >>> atualmente em desenvolvimento pelo NLnetLabs com suporte do Nic.br.
> >>>
> >>> Nos próximos meses teremos informações mais detalhadas sobre o
> >>> projeto.
> >>>
> >>> []s
> >>> Fred
> >>>
> >>> [1] https://tools.ietf.org/html/rfc6492
> >>> [2] https://nlnetlabs.nl/projects/rpki/project-plan/
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>
> >>
> >> --
> >> Douglas Fernando Fischer
> >> Engº de Controle e Automação
> >>
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> >
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação


More information about the gter mailing list