[GTER] IRR - TC - Definição de Objeto do tipo Proxy

Josivan Barbosa josivan.barbosa01 at gmail.com
Sat Dec 19 11:00:41 -03 2020 

Não entendo a dificuldade das empresas de mitigação respeitarem o AS PATH
dos clientes. É possível fazer isso facilmente com vários vendors ( Por
experiência própria, posso falar de Juniper, Huawei, BIRD e Quagga).

Há alguns anos, questionei uma empresa de mitigação nacional sobre o
seguinte "Termo de uso" do registro.br:


O(s)  bloco(s)  IP  não  pode(m)  ser segmentado(s)  para  anúncio  de
trânsito com  origem em outro  ASN que não  o alocado para  a referida
organização sem a prévia autorização do Registro.br.

O cliente ou a empresa de mitigação podem sofrer algum tipo de punição por
não respeitar esse termo?


Em sex, 18 de dez de 2020 12:31, Rubens Kuhl <rubensk at gmail.com> escreveu:

> Um proxy no TC é uma de coisas:
> - mntner diferente do aut-num nos route*
> - aut-num diferente do AS alocado no Registro.br
>
> Ou seja, mesmo os usos autorizados de originação diferente também não são
> possíveis. LOAs manuais não escalam para um projeto best-effort, e a única
> possibilidade futura(vide resposta ao Job) que existe é de usar RPKI como
> uma LOA automatizada. Assim, provedores de mitigação DDoS por enquanto
> deveriam fazer uma de duas coisas:
> 1) Fazer os anúncios de seus clientes quando em mitigação usando AS Path
> <mitigador> <cliente> ao invés de apenas <mitigador>
> 2) Usar outro IRR
>
> Notar que isso não impede que os anúncios do cliente de mitigação estejam
> registrados no TC, é só o provedor de mitigação que precisa de outro IRR.
>
>
> Rubens
>
>
> On Fri, Dec 18, 2020 at 11:10 AM Douglas Fischer <fischerdouglas at gmail.com
> >
> wrote:
>
> > Split da thread -> "[GTER] IRR - Objeto mntner deletado no TC"
> >
> > Essa thread sobre limpeza de objetos Proxy no TC suscita um
> > questionamento...
> > Quanto falamos de objeto proxy, estamos falando em relação a que?
> > Do Route(6), do Aut-Num, ou do Mntner?
> >
> > P.S.: Mantenedores do TC, por favor não queiram me matar(mais do que já é
> > usual)...
> >       O Objetivo é melhoria e entendimento de conceitos.
> >
> >
> >
> > Salvo entendimento diferente, o IRR é um mecanismo de proclames de
> objetos
> > de roteamentos que poderão ser encontrado na DFZ.
> > Algo como um mural onde alguém coloca um bilhete dizendo:
> > 1) "Hey galera, existe um ASxxx que tem essas políticas de import e
> export"
> > 2) "Hey galera, vai exisitr a rota a.b.c.0/22 anunciada pelo ASxxx"
> > 3) "Hey galera, existe uma coleção de ASNs ASaaa ASbbb ASccc ASSxxx que
> vai
> > se chamar AS-COISA
> >
> >
> > Antes de seguir com o resto da explanação e questionamento, cabe uma
> > colocação.
> >
> > "O que são Objetos IRR Proxyed?"
> > Proxy, do inglês para o português significa procuração, ou procurador.
> > Ou seja, alguém falando alguma coisa em nome de outro alguém.
> >
> > Então Objetos IRR Proxyed são "bilhetinhos no mural" que falam sobre
> coisas
> > que são de outro alguém.
> >
> >
> >
> > Voltando ao foco desse questionamento, está BEM CLARO que o TC não aceita
> > Objetos Proxyed
> > Obs.: E eu acredito que isso é ÓTIMO!
> >       Não é à toa que é uma das bases de IRR mais limpas(sem sujeira) de
> > todas.
> >       Se todas as bases de IRR tivessem adotado essa postura desde a
> > criação do protocolo RPSL, não haveria a necessidade de ter-se criado o
> > RPKI, o ASPA e toda essa parafernalha extra.
> >
> >
> > Agora vamos a dúvida conceitual acerca do que é um objeto IRR proxyed
> >  - Para o bilhetinho do tipo 1(Aut-num) não existem dúvidas que somente o
> > Owner do Objeto do ASN é que pode colar o bilhetinho no mural.
> >  - Para o bilhetinho do tipo 3(AS-SET) não existem restrições sobre um
> ASN
> > estar lista na coleção de ASNs definida por um AS-SET que não seja
> mantido
> > por ele mesmo.
> > Agora o motivo de embate:
> >  - E para o bilhetinho do tipo 2(Route ou Route6), quando esse objeto é
> > considerado Self e quando é considerado proxyed?
> >
> > Vamos analisar possíveis variações de objetos Route em IRR referentes a
> > esse bloco que poderiam existir em uma base de IRR:
> > Tomemos como exemplo o bloco 200.160.0.0/20 que é delegado ao mesmo
> owner
> > que o AS22548(NIC.BR)
> >
> > |     | ROUTE          | AS_Owner_do_Bloco | MNTNER  | ORIGIN  |
> > | 2.1 | 200.160.0.0/20 | AS22548           | AS22548 | AS22548 |
> > | 2.2 | 200.160.0.0/20 | AS22548           | AS400   | AS22548 |
> > | 2.3 | 200.160.0.0/20 | AS22548           | AS400   | AS400   |
> > | 2.4 | 200.160.0.0/20 | AS22548           | AS400   | AS1000  |
> > | 2.5 | 200.160.0.0/20 | AS22548           | AS22548 | AS1000  |
> >
> > E aí? Qual desses deveria ser considerado Proxyed?
> > Em outras palavras: "Quem é o Owner do Objeto Route(6)?"
> >
> > Segue minha opinião sobre cada possibilidade.
> > Obs.: Já tive a oportunidade de conversar com muitos operadores de rede
> > sobre esse tema, e essa opinião é ratificada por muitos deles.
> >
> > 2.1 Obviamente é um "puro sangue"
> > Bilhetinho colocado no mural pelo próprio dono do bloco, dizendo que o
> > bloco dele vai ser anunciado pelo ASN dele mesmo.
> > -> Tudo Perfeito!
> >
> > 2.2 É o exemplo de um Proxyed(procuração) "Correto"
> > Bilhetinho colocado no mural por um cara que não é o dono do bloco, mas
> ele
> > tá dizendo que esse bloco vai ser anunciado pelo ASN que é do mesmo dono
> do
> > bloco.
> > -> Não é o ideal, mas devido a muitos operadores de rede PREGUIÇOSOS,
> acaba
> > sendo necessário!
> >
> > 2.3 É o exemplo de um "Proxyed Safadão!"
> > Bilhetinho colocado no mural por um cara que não é o dono do bloco,
> dizendo
> > que esse bloco vai ser anunciado pelo ASN dele.
> > (É um proclame de hijack!)
> > -> ERRADO! Quem deu autorização a ele para falar isso sobre uma coisa que
> > não é dele?
> >
> > 2.4 É o exemplo de um "Proxyed MUITO Safadão!"
> > Bilhetinho colocado no mural por um cara qeu não é o dono do bloco,
> dizendo
> > que um bloco que não é dele vai ser anunciado por um ASN que não é nem
> dele
> > e nem dele.
> > -> Muito ERRADO! Nem o bloco nem o ASN-Origin são dele! Ele que largue
> mão
> > de ser metido a besta!
> > (Tenho uma raiva TREMENDA de quem faz isso...)
> >
> > /*E agora, verdadeiro X da quetão!*/
> >
> > 2.5 É um Objeto não Proxyado, delegando a possibilidade origem de
> prefixo,
> > correto!
> > Bilhetinho colocado no mural pelo próprio dono do bloco, dizendo que um
> > outro ASN vai anunciar o bloco dele.
> >  Isso acontece por diversos motivos. Ex:
> >    - Quando um dono de bloco IP não tem ASN(não ocorre no NIC.BR, mas é
> > comum no LACNIC e ARIN;
> >    - Quando um dono de multiplos ASNs e Multiplos Blocos IP anuncia um
> > bloco de um ASN a partir de outro(sibling);
> >    - Um ASN autoriza uma mitigadora de DDoS a anunciar os blocos dele;
> >    - Uma CDN autoriza um ASN que hospede um nó de computação seu a
> anunciar
> > seus blocos.
> > -> Correto, pois decorre de demandas legítimas engenharia e autonomia de
> > roteamento!
> >
> >
> >
> > Contei toda essa história para perguntar:
> > E aí? O TC aceita e mantém objetos com o 2.5 exemplificado nesse e-mail?
> > Ou estes são excluídos da base IRR do TC?
> >
> >
> > Em qui., 17 de dez. de 2020 às 18:26, Rubens Kuhl <rubensk at gmail.com>
> > escreveu:
> >
> > > Só que não eram. O seu mntner foi desabilitado por ter cadastrado
> > proxies.
> > > https://bgp.net.br/faq.html#0
> > >
> > >
> > > Rubens
> > >
> > >
> > >
> > > On Thu, Dec 17, 2020 at 5:43 PM Josivan Barbosa <
> > > josivan.barbosa01 at gmail.com>
> > > wrote:
> > >
> > > > Sim.
> > > >
> > > > Em qui, 17 de dez de 2020 14:24, Rubens Kuhl <rubensk at gmail.com>
> > > escreveu:
> > > >
> > > > > O mntner e os routes eram do mesmo AS que consta no Registro.br ?
> > > > >
> > > > >
> > > > > Rubens
> > > > >
> > > > > On Thu, Dec 17, 2020 at 2:11 PM Josivan Barbosa <
> > > > > josivan.barbosa01 at gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Boa tarde senhores.
> > > > > >
> > > > > > Alguém recebeu alguma notificação dizendo que o objeto mntner
> seria
> > > > > > deletado?
> > > > > >
> > > > > > Recebi uma notificação dessas dizendo que a razão era que não
> tinha
> > > > > objetos
> > > > > > associados, mas existia sim objetos route, route6 e AS-SET
> > associados
> > > > ao
> > > > > > mntner. Eles continuaram. Só o mntner foi deletado. Assim fiquei
> > > > > > impossibilitado de atualizar ou adicionar novos objetos.
> > > > > >
> > > > > > --
> > > > > > Att
> > > > > >
> > > > > > Josivan Barbosa
> > > > > > --
> > > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > >
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list