[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