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

Douglas Fischer fischerdouglas at gmail.com
Sat Dec 19 14:00:40 -03 2020 

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
>

More information about the gter mailing list