[GTER] Brainstorm - Critérios de bom comportamento num IXP

[Marcelo Gondim]

Buenas Fischer,

Tudo isso que você colocou acho importante e seria muito bom se todo AS 
tivesse a vontade que a gente tem de fazer tudo certo.

Seu item 7, por exemplo, já me causou sérios problemas de engenharia de 
tráfego e que me obrigou a usar communities de não anúncio para 
determinado AS no IX-RJ. Simplesmente prefixos que eu só anunciava para 
o IX-RJ, estavam sendo vazados para Internet e peguei o safado pelo 
Looking Glass lá fora. Você acha que adiantou eu comunicar isso para o 
AS? O amiguinho, desculpe a palavra mas, "cagou" pra gente. Esse tipo de 
atitude é que nos obriga a fazer filtros que vão de contra a ideia 
principal de estar conectado ao IX, que é trocar tráfego.

O problema é que existem participantes que agem como bons vizinhos 
enquanto outros não tem respeito ou não sabem o que fazem mesmo e não 
procuram aprender para fazer melhor. Tenho pra mim que muitos 
continuarão ainda dessa forma porque não dói no bolso deles. Na verdade 
seria melhor para o bolso deles que tudo funcionasse bem no IX.BR e com 
isso eles gastariam menos com Link IP. Daria mais qualidade para os 
assinantes deles, menos reclamação no suporte, etc. Mas acredito que 
isso não entre na cabeça de alguns.

Vide a lista da vergonha da CAIDA de spoofing, que a gente sempre recebe 
aqui e quantos ali são recorrentes. Seria interessante pontuar essas 
coisas nos participantes, se vai resolver algo aí são outros quinhentos.

Como você colocou os sistemas são autônomos e se não houver alguma forma 
de "corrigir" o amiguinho, tudo vai continuar como sempre foi.

Ao meu ver para isso funcionar teria que:

1º Identificar tudo isso que você colocou para cada participante no 
IX.BR, fazendo algum esquema de pontuação, como a gente vê no mundo da 
classificação de spam. Cada coisa errada conta uma pontuação.

2º Se o participante chegar a uma determinada pontuação, este será 
jogado para a quarentena, avisado dos problemas que foram encontrados e 
solicitando a correção deles.

Ao meu ver somente assim esses problemas, que você citou, serão 
corrigidos. Fora isso vai ser um monte de indicativo sem resultado 
prático. Infelizmente meu amigo.

Em 17/08/2021 07:05, Douglas Fischer escreveu:
> Aoooba! Bão?
>
> Estive conversando com um amigo sobre quais seriam os critérios para dizer
> que um participante está "se comportando adequadamente" num IXP.
> Algumas ideias surgiram... Mas com certeza nem de longe se esgotaram as
> possibilidades.
> Então resolvi jogar uma gasolina no braseiro para ver se saem mais algumas
> boas ideias.
> E vim pedir ajuda para os abiguinhos!
>
> Meu sonho seria poder medir cada um dos itens da lista que criarmos a
> partir daqui, e criar um status de cada item desses para cada participante.
>   - Criar um Widget no portal do meu.ix.br com EmotIcons 😍 😪 para cada um
> desses itens em cada participante.
>   - Colocar em algum local público, um Score de quantos desses itens o
> participante está em conformidade.
>
>
> Bora pensar juntos sobre isso?
>
> IMPORTANTE!
> Fundamente sua argumentação! Você pode não concordar com quaisquer dos
> pontos colocados aqui (por mim ou por outros colegas), mas não venha com
> "achismos" e opiniões impostas!
> LEIA E RELEIA as regrinhas a seguir antes de sair despejando veneno.
>
> Antes de começar, vamos colocar umas regrinhas...
> - Não vale xingar o coleguinha!
> - Vamos nos ater aos comportamentos DOS PARTICIPANTES em relação AO IXP, se
> não a coisa fica sem foco, e não seremos produtivos.
> - Existem outros IXPs no mundo e no Brasil além do IX.BR.
>    - Sim, estamos na lista do GTER, e o IXP mais diretamente ligado a essa
> comunidade é o IX.BR. Mas precisamos lembrar que existem outros IXPs e o
> bom comportamento serve para eles também.
> - Lembremos que AS significa (S)istema (A)utônomo, então, cada um tem a
> AUTONOMIA para escolher suas políticas de roteamento, até o limite que isso
> não desrespeite o coleguinha.
>      Um exemplo do que isso significa:
>          - Se um ASN quer o não anunciar ou aceitar certas rotas, É UMA
> ESCOLHA DELE!
>          - Mas se você desrespeitar as rotas que ele anunciou, e meter rota
> estática para cima dele, é SAFADEZA.
>      - Também não vale falar "Mas o IX.BR tem que obrigar eles a aceitarem
> minhas rotas.".
> - Se o que o participante está fazendo vai contra as RFCs, BCPs, e
> BCOPs, normas internas do IXP, o participante TÁ ERRADO!
>     - Caso exista uma divergência entre RFCs, BCPs, BCOPs, e normas do IXP,
> a norma do IXP pois existe um termo de acordo específico para isso.
> - Se for sugerir mais regras de bom comportamento, é ideal que sugira como
> esse bom/mal comportamento pode ser medido de alguma forma.
>
>
>
>
> Lista de possíveis definições de mal comportamento de um participante de um
> Internet Exchange Point, ou ponto de troca de tráfego.
>
> 1 - Participante que excede o tempo esperado nas respostas e interações dos
> Tickets de suporte com o IXP.
>
> 2 - Participante que anuncia rotas para os Route-Server rotas que não devem
> ser anunciadas:
>        Ex.: Rota default, Rotas com ASN de Tier1 ou de OTTs no AS-Path,
> Rotas com RPKI Inválido, rotas com tamanho de máscara fora do permitido.
>        Obs.: Principalmente aqueles que fazem isso e "esquecem" de conferir
> no Looking Glass se existem rotas de seus Peers sendo filtradas pelos
> Route-Servers.
>
> 3 - Participante que derruba sessão BGP com os Route-Servers sem motivo.
>         Obs.1: Mesmo que o SISTEMA AUTÔNOMO não troque rotas através do
> Route-Server, manter a sessão ativa ajuda o próprio IXP a monitorar a
> qualidade da operação oferecida.
>         Obs.2: Se sua caixa não tem capacidade suficiente processar as
> trocas de mensagens com os Route-Server, apenas aplique um filtro
> "NEGA-TUDO" tanto no Import quanto no Export, mas mantenha a sessão UP.
>
> 4 - Participante que configura o next-hop de suas rotas com IP diferente do
> seu IP de sua sessão, exceto para os casos de Black Hole.
>
> 5 - Participante que configura os peers do Route-Servers com tipo errado em
> seu equipamento.
>        Ex.: Configurar os peers do Route-Server como Route-Server-Client, ou
> como Route-Reflector-Client.
>
> 6 - Participante que anunciam para seus Upstream e/ou Downstream a sub-rede
> da LAN dos IXPs aos quais estão conectados.
>
> 7 - Participante que anunciam para seus Upstream rotas aprendidas pelo IXP.
>
> 8 - Participante que não aplica uma filtragem básica das rotas anunciadas
> pelos Route-Servers
>        Ex.: Rejeitar Bogons, rejeitar máscara inválida, Rejeitar RPKI
> Inválido.
>
> 9 - Participante que opta por participar da troca de rotas do IXP, e não
> aplicam as ações de communities para Black Hole definidas pelo IXP.
>        (Aceitar /32 e /128 somente que estejam com a community de
> Black-Hole, e manter o next-hop definido na rota)
>
> 10 - Participante que aponta rotas estáticas (ou até através de
> subterfúgios dinâmicos) para ASNs que fizeram ajustes de rotas para que seu
> ASN não recebesse aquelas rotas.
>
> 11 - Participante que envia pacotes com Origens de Bogons ou Martians para
> o barramento do IXP.
>
> 12 - Participante que ativa Sessões BGP(em modo ativo) contra IPs de outros
> participantes no ATM, sem que haja um acordo prévio entre as partes.
>
> 13 - Participante que envia pacotes com MAC-Address de Origem diferente dos
> registrados como liberados em seu cadastro na base do IXP.
>
> 14 - Participante que envia pacotes de tipos indevidos para a malha do IXP:
>      14.1 - PADI de PPPoE
>      14.2 - DHCP Request
>      14.3 - Hellos de OSPFv2 ou v3), RIP ou ISIS.
>      14.4 - ARP-Gratuito
>      14.4 - ICMPv6-RA
>
> 15 - Participante que configuram IPs v4 e/ou v6 de diferentes daqueles
> definidos pela coordenação do IXP para aquele participante naquela vlan.
>          Ex.: IPv6 na vlan de IPv4 only, IPv4 na vlan de IPv6, 10.10.10.1/30
> como secundário, IP de outro participante em sua interface.
>          Gerando ARP-Request e ICMPv6-ND sem nenhum vínculo com as sub-redes
> do IXP, e podem causar IPs duplicados ou Man-in-the-Middle involuntário.
>
> 16 - Participantes que configuram Timeouts muito baixos para entradas da
> tabela ARP e ND.
>          Geram um volume excessivo de pacotes de Broadcast ou Multicast.
>
> 17 - Participantes que configuram regras de proteção de CPU, em especial
> com relação a ARP e ICMPv6-ND muito restritas.
>          Geram muitas falhas de resolução de ARP ou ND
>
> 18 - Participantes que, por inadequações de suas próprias configurações, ou
> dos serviços de transporte contratado por eles mesmos, apresentam problema
> para manter toda a quantidade de entradas MAC, ARP, e ND.
>          Geram problemas nas comunicações entre os participantes.
>
>
>
-- 
   ⢀⣴⠾⠻⢶⣦⠀  Marcelo Gondim
   ⣾⠁⢠⠒⠀⣿⡁  Sysadmin - https://www.linuxinfo.com.br
   ⢿⡄⠘⠷⠚⠋   DA04 922E 78B3 44A5 3C8D 23D0 8DB5 571E E151 4E19
   ⠈⠳⣄⠀⠀⠀⠀  Logic will get you from A to B. Imagination will take you everywhere. (Albert Einstein)