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

Douglas Fischer fischerdouglas at gmail.com
Fri Dec 18 11:09:15 -03 2020 

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

More information about the gter mailing list