[..]

...

Om de mensen wat zoekwerk te besparen :

ORF - Outbound Route Filter

Vertel je peer wat je niet wilt zien aan routes, en je krijgt ze ook niet.

Ik had het er in mijn hoofd bij getyped, alleen je moet dus niet tig dingen door elkaar doen, I forgot. Niet iedereen zal hier mee bekend zijn nog, het is vrij nieuw ook.

Je kan momenteel dus afaik alle filters die je normaal definieert zoals "10.0.0.0/8 le 32" per BGP aan je peer vertellen maar ook ASpath filters zijn mogelijk. Nadeel was dus dat dit aan je peer wordt verteld en niet verder aan andere routers.

Dat lijkt me voor de hand liggen, want dat *jij* die prefixen niet wilt zien, wil niet zeggen dat anderen ze ook niet willen. Dus zou je jouw AS erbij moeten voegen (AS 123 wil filterset xyz). Maar ASen die niet rechtstreeks met jou communiceren, kunnen daar toch niks mee, want hun neigbours willen die prefixen wel, dus kunnen ze die voor jou niet droppen. Kortom, route filters alleen tussen BGP neighbours vind ik niet zo vreemd. Puur ORF lijkt dus meer een add-on die nuttig is voor partijen die geen full routing ontvangen, en ook zelf niet filteren, als ik de (cisco) manuals zo bekijk. [..]

Je kan momenteel een cisco/zebra oid pakken en dan de routes van ddos'ers (sources) announcen met een bepaalde community oid. Zie oa. http://www.secsup.org/CustomerBlackHole/

Die pagina beschrijft de manier om bij je upstream een bepaalde *destination* (binnen je eigen netwerk ;-) ) te laten blackholen. Zeker ook nuttig, wanneer je upstream verbinding volledig dicht zit. Maar het blijft natuurlijk een DoS; Hiermee hebben alleen je andere services er geen last meer van. De slimme truken om, via uRPF en een BGP bron, *source* reeksen te droppen beper ken zich toch typisch tot je eigen netwerk.

...

Ik heb een beetje het idee dat degenen die zouden deelnemen aan zoiets degenen zijn die toch al weinig een bron van problemen zijn, en indien wel, toch al snel bereikbaar om er op de gewone manier wat aan te doen.

Ja, dat is helaas zeker zo, maar als je dus samen werkt kan je iig zorgen dat die traffic niet bij de deelnemers komen. Een upstream zou bovenstaand mechanisme kunnen maken waardoor hun die IP's al nullrouten, geen traffic naar jou.

Een onderling destination blackhole zou best kunnen, maar het aantal mensen hier dat elkaar de mogelijkheid zou durven geven om *source* reeksen te blackholen lijkt me toch wel wat kleiner. Dat is nou echt een geval waarmee je geen fuckups wilt. (Idem voor upstream providers : al je klanten de mogelijkheid geven om naar behoefte source reeksen netwerk breed te droppen ? Uhhh nee. Of zelfs border-router (waar meer dan 1 klant aan hangt) breed ? )

Filteren van die prefixen is netter en sneller though.

Met alleen het filteren van prefixen heb je nog niks aan een DDos gedaan. Alleen kan uRPF nu verkeer droppen vanwege het ontbreken van een route.

...

...

een filter definieren en *flop* al je routers snappen hem. (u)RPF er bij et tada. Uitgebreide voorbeelden op aanvraag :)

Bovenstaande kan ieder voor zich al doen, naar source danwel destinations droppen en de informatie daarvoor via (i)BGP verspreiden. Wat sneller en makkelijker dan op een aantal plaatsen allemaal filters zetten.

Dat filters plaatsen kan dan op 1 plek want je verzend de info per BGP en ORF. Huidige ORF werkt nu dus alleen tussen 2 routers.

Wat ik nog even niet zie is wat je precies zou willen filteren. Als iemand upstream een destination (binnen zijn eigen AS) wil laten blackholen, prima. Wil iemand een *source* reeks, uit een ander AS, verderop laten blackholen, wel, daar komt nogal een stukje vertrouwen en controle bij kijken, om het zacht uit te drukken. Als je de blackhole zou kunnen beperken tot een bepaalde source reeks *en gericht aan het netwerk van de klager*, zou het niet zo'n probleem zijn. Maar de uiteindelijke forwarding table in een router is niet peer-specifiek. Boudewijn