[ITNOG] DDos Mitigation all'Internet Exchange?

[Luca Cicchelli]

Marco,
personalmente concordo con quanto scritto da Marco (d’Itri) e da Valeria sulla naturalità dell’Internet Exchange. 
Aggiungo però che in TOP-IX alcuni afferenti nostri consorziati ci hanno chiesto di mettere in piedi un servizio di mitigazione che ovviamente si attivi sulla base di loro richiesta e quindi non intervenga a priori.
Al momento vi sono varie ipotesi che, appena discusse al nostro interno, posso condividere per avere feedback.


--
Luca

Il giorno 13/gen/2014, alle ore 08:44, Gioanola, Marco <mgioanola@arbor.net> ha scritto:

> On 10/1/14 7:13 PM, "Marco d'Itri" <md@Linux.IT> wrote:
> 
> 
>> 
>> Come giustamente notato, è follia pensare che qualcuno possa fare
>> blackholing di un IP sulla piattaforma del IX in un modo che riguardi
>> anche terzi non interessati alla questione.
> 
> Ovviamente è follia, e io non intendevo suggerire questo. Ciò che penso si
> potrebbe forse realizzare è un sistema di blackholing (o ancora meglio, di
> mitigation "intelligente") azionato dall'AS vittima e implementato dall'IX
> prima che l'attacco raggiunga, appunto, la vittima.
> 
> Altrettanto ovviamente, è necessario non coinvolgere "terzi non
> interessati", e ciò si realizza solo facendo blackholing (o mitigation)
> del solo /32 sotto attacco, su iniziativa dell'AS relativo.
> 
>> D'altra parte, se l'unica soluzione proposta a un DDoS è chiudere una o
>> più sessioni al IX (e ricordiamoci dei route server che complicano le
>> cose...) allora siamo molto vicini al punto in cui questo non è più
>> adeguato.
> 
> Concordo, non è adeguato per nulla, in quanto dobbiamo assumere il caso
> peggiore in cui l'attacco ddos (*distributed* :-) dos) giunge
> omogeneamente da tutti i peer.
> 
>> 
>> 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?
> 
>> - 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?
> In entrambi i casi direi che gli impatti sono trascurabili: se mi evitano
> un down di ore, sia i secondi necessari a propagare una null route che gli
> eventuali ms introdotti ad uno scrubbing center mi sembrano il minore dei
> mali.
> 
>> - non scala con l'aumentare dei peer
> 
> Beh, questo dipende appunto da come viene realizzata la soluzione.
> 
>> 
>> La soluzione più elegante sarebbe estendere ai propri peer le funzioni
>> di blackholing controllato via BGP che già si mettono a disposizione dei
>> propri clienti.
> 
> Concordo; è qui che volevo arrivare.
> 
>> È abbastanza ovvio però che questo non può funzionare a meno che alcuni
>> grandi reti inizino ad imporlo come condizione per fare peering, visto
>> che chi dovrebbe fare il lavoro (la sorgente del attacco) non sarebbe
>> chi ne beneficierà (il destinatario del attacco).
>> 
>> Molto più semplice la soluzione proposta da AMS-IX nell'ultima slide,
>> di fare una cosa simile mediante i route server. Però richiede
>> necessariamente che tutte le route siano correttamente registrate nel
>> IRR e filtrate e, diversamente da MIX e DE-CIX, AMS-IX ha già detto di
>> non averne voglia.
>> Visto che qui ne avremmo la possibilità, forse possiamo esplorare
>> meglio questa opzione: proviamo a riflettere un po' su cosa
>> comporterebbe.
>> Forse non era chiaro a tutti, ma appunto lo scopo di questa funzione
>> sarebbe fare blackholing del *proprio* IP destinazione dell'attacco,
>> non delle sorgenti...
>> 
>> Dopo questo rimane solo che l'IX fornisca una API che permetta di
>> installare sulla propria porta di una ACL personalizzata, che però deve
>> essere L3 per essere utile. Questa è la soluzione che non richiede
>> alcuno sforzo implementativo ai membri del IX, ma richiede che gli
>> switch possano gestire ACL L3 sulle porte L2, e senza problemi di
>> prestazioni. (E su questo punto non sono preparato.)
> 
> Una tecnologia che promette molto a questo riguardo è Flow Spec. Vorrei
> aggiungere qualche link ma sono dietro una pessima connessione e non
> riesco a controllare.
> Così alla cieca, direi
> http://www.monkey.org/~labovit/papers/labovitz-bgp-flowspec.pdf e
> http://njetwork.wordpress.com/2013/04/30/mitigating-ddos-attacks-with-bgp-f
> low-specification/
> 
> 
>> 
>>> 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.
> Tralasciando i "dettagli" politici e/o commerciali :-) francamente mi
> sembra una soluzione di facile implementazione e basso costo operativo:
> banalizzando, serve una telefonata per mettersi d'accordo e tre righe di
> configurazione sui router.
> 
> saluti
> 
> 
> --
> Marco Gioanola
> Consulting Engineer, EMEA
> Arbor Networks
> mgioanola@arbor.net
> +39 339 7584747 (m)
> 
> --> See you at Cisco Live, Jan.28th-30th, Milano <--
> 
> Please be advised that this email may contain confidential information. If
> you are not the intended recipient, please notify us by email by replying
> to the sender and delete this message. The sender disclaims that the
> content of this email constitutes an offer to enter into, or the
> acceptance of, any agreement; provided that the foregoing does not
> invalidate the binding effect of any digital or other electronic
> reproduction of a manual signature that is included in any attachment.
> 
> 
> 
> 
> 
>> 
> 
> 
> -- 
> Mailing list info: http://lists.itnog.it/listinfo/itnog

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.itnog.it/pipermail/itnog/attachments/20140113/922c47d6/attachment.html>