[GTER] Co-operative DDoS Mitigation

[Fabiano Ribeiro]

     Não tinha pensado nisso, é algo que poderia ser programado em um
sistema operacional.
    A maior dificuldade seria manter sincronizado as alterações das rotas
do peer com as regras do ipfw. Um código que rode de tempo em tempo seria
uma puta de uma gambiarra. O certo era uma interação do daemon que a cada
update uma trigger pudesse ser chamada. Alguém já viu algo assim ?

Em 23 de outubro de 2015 15:24, Eduardo Schoedler <listas at esds.com.br>
escreveu:

> Em 23 de outubro de 2015 13:28, Rubens Kuhl <rubensk at gmail.com> escreveu:
>
> > >
> > >
> > > Mas falando de Cisco, RPF fica no hardware.
> > > Se não me engano Juniper é a mesma coisa.
> > >
> > > RPF custo de performance? TEM!
> > > Ou seja, numa conta de padeiro, teria que comprar uma caixa com o
> > > DOBRO(provavelmente menos) do poder do que estava planejando...
> > >
> >
> > Em hardware-forwarding, RPF gera um problema de contenção, pois a mesma
> > tabela de roteamento precisa ser consultada para forwarding e para o
> drop.
> > Assim, RPF tipicamente divide a performance pela metade.
> >
> > E ao contrário do que você afirmou antes, muitas vezes em
> > hardware-forwarding ACL também é feita em hardware em paralelo com o
> > roteamento para as input ACLs, então apenas output ACLs precisam esperar
> o
> > roteamento... um sistema configurado apenas com input ACLs pode operar
> mais
> > rapidamente que um sistema com RPF por causa disso. Alguns sistemas
> > conseguem combinar as output ACLs com a tabela de roteamento e otimizar
> > isso, mas é raro.
> >
>
> Tenho tido problemas RPF em clientes BGP.
> Alguns simplesmente não anunciam o bloco todo, acaba ocorrendo drop na
> entrada da interface.
> A solução da ACL é melhor nesse caso, e você pode usar o mesmo prefix-list
> na interface e nos filtros de bgp, pelo menos no caso do Junos.
>
> Boa ideia.
>
> --
> Eduardo Schoedler
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>