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

[Douglas Fischer]

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