RE: Effective ways to deal with DDoS attacks?
On 5/3/02 12:05 PM, "Stephen Griffin" <stephen.griffin@rcn.com> wrote:
Most Cisco boxes have 3 related modes of uRPF: 1) pure RPF, if forwarding path back to source doesn't go via interface packet received from, then dump. I believe, but am not positive, that it will handle equal-cost-multipath ok in situations where that exists. 2) acl exceptions, if source matches the acl, allow the packet 3) not-so-pure RPF, if there is _any_ forwarding path back to the source via _any_ interface, then accept.
Speaking of this, has anyone seen Barry Greene's and Philip Smith's new book, "Cisco ISP Essentials"? It covers the uRPF strict mode as well using uRPF with multihoming examples, etc. I wish we could hear from them about it on this list. Actually, I'd rather hear it from people using it. Are there any configs out there that show uRPF with multihoming examples especially in ISP POP or IDC's? Let's say you have multiple ECMP on the back side and multiple transit providers and peers taking a mix of full and peering routes at the edge -- what would that look like?
for single-homed customers, simple uRPF for multihomed customers, acl exceptions based upon their registered IRR-policy, since the customer should already be registering in the IRR you have a list of all networks reachable via the customer, regardless of the actual real-time announcements or policy applications (prepending, localpref tweaks, etc) for peers that are clued-in, again acl exceptions based upon the peers registered policy for non-clued peers, accept based upon any available forwarding path [hopefully, by the 100th time you beat on the peer about spoofed crud coming from them, they'll get religion and register, since you'll have less overall spoofing to track down, you can devote it to slapping them around more]
ACL exceptions based on IRR policy? So you are using RtConfig or similar scripts to build your uRPF rules? Can you clarify this a bit more, or give some examples? On-list or off-list is fine with me. Thanks -dre
participants (1)
-
Gironda, Andre