
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Marco,<div>personalmente concordo con quanto scritto da Marco (d’Itri) e da Valeria sulla naturalità dell’Internet Exchange. </div><div>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.</div><div>Al momento vi sono varie ipotesi che, appena discusse al nostro interno, posso condividere per avere feedback.</div><div><br></div><div><br><div>

<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Luca</div></div></span></div></span></span>

</div>

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