Though placing a /32 to a discarded interface helps the situation, you are now fully disabling your client that uses the /32... I do agree that it definitely helps the situation... specially when the attack is a few mil pps or perhaps even few gigs/sec in which case a customer /32 or bigger being down is about 100x better then your network being down. so my question is then how do you use the same method for your peering sessions (assuming you do peering on a private or public level)... seeing how 95% of peers will not allow such specific entries such as /32 into their tables... so in case of an attack you are left with either having to take down the peering session or stop advertising the prefix though that peer. Just curious as to how you go about it... cheers, -Payam
I hate to stir the flames again, but this idea sounds a lot like RBLs. :)
All kidding aside, I'm curious as to when we will reach the point where the devices of our networks will be able to share information regarding sporadic bursts or predefined traffic patterns in network traffic within a certain time frame, determine it is a related outgoing (or incoming) attack, and mitigate/stop the traffic. I think it certainly is possible to accomplish this on a per-router level, but being able to have the devices communicate and share information between one another is a completely separate thing. (New protocol perhaps.)
The only real method that I really have in my toolkit to stop incoming DDoS on a AS-wide perspective is originating a /32 within an AS with a next-hop of a discard interface.
Something similar to that nature but more flexible and designed for the sole purpose of preventing/stopping abuse would be a very nice feature.
Cheers. -Michael
-- Michael Nicks Network Engineer KanREN e: mtnicks@kanren.net o: +1-785-856-9800 x221 m: +1-913-378-6516
Payam Tarverdyan Chychi wrote:
Ive been reading on this subject for the last several weeks and it seems as if everyone just like to come up with out of the box ideas that are not realistic for todays network environments
J.Oquendo, thanks for the Smurf example as there are still admins/engineers at large networks that have no clue as to what they are doing so QoS is for sure out of the question.. at least at this time.
Depending on agents to take actions and protecting our networks is even a bigger joke. Back in late 90s where kiddies were using the simplest types of C&C, open wide irc networks with visible Channels and no encryptions and agents couldnt do anything unless the attack was big enough to take down Amazon, yahoo, Microsoft or some other major provider with enough $$$ to start an investigation.
So what makes you think that agents are of any help in todays world where c&c have gotten so much more sophisticated, use backup private servers, encryption, tunneling and much much more..
In my opinion, the only way to really start cracking down on c&c and put an end to it is the cooperation of major ISPs. I realize that most isps cant/wont setup a security team to just investigate c&c / attacks (would this really fall under the Abuse team?) but perhaps If all major networks worked together and created a active db list of c&c found either on their networks or attacking ones network then it would be much much easier to trace back c&c and dispose of them.
Unfortunately, we dont live in a perfect world and most isps hate sharing any information I guess its better for them to have a bigger ego than a safer / more stable network
Please feel free to correct me if I am wrong
-Payam
-- -- Payam Tarverdyan Chychi Network Analyst