[GTER] IRR - TC - Definição de Objeto do tipo Proxy
Josivan Barbosa
josivan.barbosa01 at gmail.com
Sat Dec 19 17:57:36 -03 2020
Se pegam um upstream com filtro de AS PATH ou mesmo validando a origem dos
anúncios com RPKI, unitilizam a sua solução.
Em sáb, 19 de dez de 2020 14:01, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:
> Existe uma justificativa verdadeira, mas completamente contornável, para
> isso.
>
> É o conceito de traffic attraction.
>
> Se a rede atacada está anunciando um bloco A.B.C.0/24 e a empresa de
> mitigação está anunciando esse mesmo A.B.C.0/24 colocando seu AS no
> caminho(como deve ser), a rota vencedora vai ser a do ASN original(que está
> sendo atacado).
>
> Então, o que as empresas de mitigação fazem, é sequestrar o prefixo
> anunciando ele com seu próprio ASN como origem.
>
> É uma técnica porca e safada! Eu sei...
> Mas é prática comum entre as mitigadoras mais baratinhas...
>
>
> O mais coerente seria fazer o que chamam de prepend negativo na rota da
> mitigadora(que nada mais é que fazer prepend em todas as outras rotas que
> não a da mitigadora).
>
> Isso já resolveria o problema.
> Mas sempre tem uns que gostam de agir com mais grosseria que exigem que a
> empresa atacada remova todos os anúncios que não o da mitigadora... Isso dá
> tanta, mas tanta dor de barriga que mereceria uma apresentação de uma 30
> minutos só pra falar disso.
>
>
> Em sáb, 19 de dez de 2020 11:01, Josivan Barbosa <
> josivan.barbosa01 at gmail.com> escreveu:
>
> > 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
> > >
> > --
> > 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