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

Rubens Kuhl rubensk at gmail.com
Fri Dec 18 12:30:46 -03 2020 

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
>

More information about the gter mailing list