[ITNOG] DDos Mitigation all'Internet Exchange?

Marco d'Itri md@Linux.IT
Lun 13 Gen 2014 12:39:22 CET


On Jan 13, "Gioanola, Marco" <mgioanola@arbor.net> wrote:

> >Partiamo pure dal presupposto che qualsiasi soluzione che richieda di
> >contattare i propri peer e convincerli a fare cose dal loro lato:
> >- non è ovvio che funzioni (anzi...)
> Quali sono i tuoi dubbi a riguardo?
Molti non hanno le competenze tecniche e/o gli incentivi economici 
e sociali per fare cose come questa.

> >- comunque quando funziona ha una latenza troppo alta
> "Latenza" nel senso di tempo necessario ad attivare il
> blackholing/mitigation o nel senso di "delay" introdotto dai processi di
> mitigation?
Nel senso che se devo contattare ogni volta i peer da cui mi arriva un 
attacco per farli filtrare dal loro lato, in genere finisce prima 
l'attacco.

> Una tecnologia che promette molto a questo riguardo è Flow Spec. Vorrei
Conosco flowspec, ma serve a poco finché lo implementa solo Juniper.
(E in ogni caso sarebbe pericolosissimo permettere a un peer di usare 
direttamente flowspec verso la propria rete, per esempio permetterebbe 
di saltare da una VRF all'altra.)

> >> esiste, la frequenza dell'adozione di accordi bilaterali tra peer per
> >> l'utilizzo di community di null route?
> >Io non ne ho mai visto uno, e tu?
> Uno dei miei clienti (un ISP "regionale" italiano) ha accordi coi propri
> upstream (che sono in numero ridotto) per esportare verso di loro annunci
> /32 taggati con una community concordata per il blackhole.
Dai miei *clienti* e verso i miei transiti lo faccio almeno dal 2006, si
parlava di peer:
http://www.linux.it/~md/projects/WWW/text/blackholing.html .

On Jan 13, Pier Carlo Chiodi <pc.chiodi@gmail.com> wrote:

> Anche a mio avviso l'implementazione mediante BGP communities è la più
> indolore e facilmente attuabile; in molti scenari immagino che si
> tratterebbe soltanto di estendere meccanismi già esistenti e consolidati.
Infatti stiamo studiando come implementarla a MINAP: usiamo rpsltool 
per generare i filtri dei route server, quindi sarebbe piuttosto 
semplice gestire anche questo.

> Si potrebbe anche pensare ad un'implementazione graduale; in prima
> battuta mediante la formalizzazione da parte dell'IX di una community
> sotto il proprio ASN ad uso e consumo dei peerers e, in un secondo
Non può essere standardizzato perché ciascuno ha un proprio schema di 
community, quindi se non si passa per i route server l'IX non può avere 
nemmeno un ruolo di coordinamento.

-- 
ciao,
Marco


Maggiori informazioni sulla lista itnog