[GTER] Um DDoS lotou seu enlace. Você sabe para onde estão indo seus pacotes BGP?

[Henrique de Moraes Holschuh]

Senhores (as),

Provavelmente a estas alturas, todos já devem estar a par da mais nova
forma de amplificar o estrago que uma instabilidade BGP forçada pode
causar (CXPST).

Alguns detalhes que me saltaram à vista, depois de ler os devidos papers
(nem em resumos da New Scientist dá para confiar hoje em dia...):

Ref:
     http://www-users.cs.umn.edu/~schuch/papers/lci-ndss.pdf

http://www.isoc.org/isoc/conferences/ndss/07/papers/low-rate_TCP-targeted_DOS_attacks.pdf


Eis uma listinha estilo "opsec lite" para pensar:

1.  Proteção do tráfego de roteamento contra sufocamento no data plane:

     1a. Quantos de nós realmente testam se os pacotes BGP, OSPF, RIP,
         estão passando no enlace marcados com a prioridade mais alta?

         Era para o roteador/Quagga/Bird/Vyatta já marcar isso de forma
         padrão, mas...

     1b. Quantos de nós realmente testam se o roteador está priorizando
         na fila de saída os pacotes marcados?

     1c. Quantos de nós remarcam outros pacotes de alta prioridade para
         alguma coisa mais baixa que a prioridade dos pacotes do control
         plane?  Sem isso, basta a origem do DDoS marcar os pacotes
         dele...

     * Note que a marcação não precisa ser honrada no backbone inteiro,
       é apenas no(s) enlace(s) entre os eBGP speakers.

     * Sessões eBGP multihop dificilmente vão sobreviver a um ataque
       destes, algo que se deve levar em conta...

2.  Proteção do control plane contra sufocamento via data plane:
     (isso está nos slides da Cisco, tenho certeza)

     2a. Quantos de nós protege o roteador contra DDoS direto, usando
         GTSM, ACLs, e o engine de QoS para evitar que uma enxurrada
         de tráfego consiga chegar na CPU / software router?

     2b. E quantos tiveram o cuidado de garantir que, ao proteger
         contra DDoS a CPU, deixaram a porta aberta para o tráfego
         que PRECISA chegar na CPU do roteador a qualquer custo
         (tráfego BGP, OSPF... legítimo) ?


3.  Proteção do BGP contra sufocamento por instabilidade (excesso
     de updates)

     Não sei o suficiente para opinar.  Ideias ?

     Como evitar que uma enxurrada de updates _válidas_ torne o
     roteador instável, ou atrapalhe tanto a convergência a ponto
     de muitas rotas serem perdidas ou incorretas (ou seja
     causar blackholes) ?

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.