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

[Douglas Fischer]

Privadamente um amigo mencionou uma coisa bem importante, e resolvi trazer
para cá.

Coisas que NÃO SERVEM como argumento:
"Eu sou uma SUPER MEGA HYPER grande empresa, e não vou me sujeitar a essa,
essa e aquela regra..."
"Ainnn... mas eu sou pequenininho, e não tenho recursos para fazer isso"

Pó pará!
As regras que servem para um, serve para o outro!

Alguns exemplos para tornar claro.
- Pode ser a maior empresa do mundo, se anunciar RPKI Inválido, tá fazendo
besteira e não tem colher de chá!
- Pode ser um Mini-ISP, só com um Server Soft-Router, ou um Mikrotik, NÃO
TEM COMO TOLERAR FILTRO DE ROTAS MAL-FEITO!


E lembrando claro, independente de grande ou pequeno, a Autonomia do
Sistema Autônomo não se discute!
O lance é: "Quer jogar bola junto com a galera? Não vale dar carrinho!"



Em ter., 17 de ago. de 2021 às 07:05, Douglas Fischer <
fischerdouglas at gmail.com> 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.
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação