|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Effective ways to deal with DDoS attacks?
In the referenced message, Iljitsch van Beijnum said: > On Fri, 3 May 2002, Stephen Griffin wrote: > > > 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) > > This doesn't make any sense. If you use uRPF on a customer interface, it > will check the packets coming in from the customer to see if they match > the prefixes you route to that customer. So as long as what you route to > them and what they use as source addresses are identical, you don't have a > problem. think MEDs and localpref twiddles., identical prefixes do not necessarily relate to best paths. > For multihomed customers, these sets of prefixes should be identical, just > like with single homed customers. The only time when those sets of > prefixes is NOT the same is for a backup connection. But if a connection > is a pure backup for incoming traffic, it's reasonable to assume it's a > pure backup for outgoing traffic as well, so as long as the backup is > dormant, you don't see any traffic so no uRPF problems. Not always the case, customer behaviour can not be accurately modeled. > Using an exception access list is pretty silly: if you're going through > the trouble of listing all a cutomer's prefixes in a list, you might as > well just apply this acl to the interface rather than uRPF with the acl as > exceptions. the acl will only be used on packets failing the rpf check. interface acls get applied to all traffic. > There is another way to handle backups: you can also set the weight to a > higher value for customer routes. This way, the router connecting to the > customer will always use the routes announced by the customer, even if the > rest of the network deems them inferior to another route to this customer > because of a lower local pref, a higher MED or a longer AS path. > > This mechanism is also useful for peering: because of the higher weight, > the border router will always prefer the exchange (or private peering > link) for all traffic to the customer, so uRPF works. The rest of the > network can still decide to send the traffic to another exchange point. I'm quite leery of having islands of widely divergent policy, and I wouldn't think it would help if you have multiple non-equal-cost-paths on the same router with which to accept traffic on. > > 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] > > If people stop peering with those network polluters they'll clean up their > act soon enough. This is unlikely to occur, unfortunately, so merely making it as annoying as possible for polluters and less annoying as possible for non-polluters, is probably the way to go. > > you should also in/egress filter known bogons at all borders, like > > src/dst in rfc1918 > > src/dst in class e > > Why? That doesn't buy you much except job security because someone > spending so much time on those impressive filters can't be missed of > course. Because it is polite to not send crap to your neighbors, and advantageous to not have crap coming into your network. > > src in class d (not dest, however) > > Some multicast apps set the source to the group address as well. How... odd... > Iljitsch van Beijnum
|