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, Steven W. Raymond said: > > Stephen Griffin wrote: > > where for RPF, or traditional traffic filter is > > access-list foo {permit|deny} ip source wildbits dest wildbits > > Hrrmm, since uRPF checks only the source address, the "standard ACL" > seems most appropriate to me. true, although I'ld still use extended acl or prefix-list for route-filtering. > > I guess you could use a "standard acl" however I wouldn't recommend > > it for filtering routes. Even if you could use prefix-lists for > > uRPF, you would want to match more-specifics, whereas generally you > > don't want to match (unbounded) more-specifics on route filters. > > > > RtConfig can generate either style from IRR data. It isn't too hard > > to generate either style from a manual list either. > > It certainly wouldn't hurt to have both a prefix-list for route > filtering and ACL for the uRPF exceptions. It's just that I am lazy and > thought it would be "neat" for one list to fulfill both requirements, > since it is essentially the same input data in two different formats. I prefer to think of it as optimal, rather than lazy. :) > > How would uRPF respond to the following prefix-list? > > ip prefix-list foo deny 0.0.0.0/0 ge 25 > > The implicit deny @ the end of the prefix-list seems a better way to > accomplish the same result as above (deny anything longer than /24). In > other words, instead use a prefix-list containing an explicit list of > the permitted networks, rather than pattern matching to deny what bad > stuff might be announced. I agree that explicit matches are good. My concern is when you build in safeguards for a customer-input stream (any automated system not requiring clued review). > > ip prefix-list foo permit 1.2.3.0/24 > > ip prefix-list foo permit 0.0.0.0/0 le 16 > > > > Would it accept all sources within 1.2.3.0/24? What about 10.0.0.0/8? > > I guess it could ignore "ge" and "le". Although how it would resolve > > conflicts is an unknown. It might try to correspond to actual prefixes, but > > that seems unlikely. > > To restate above, just permit explicit networks customer plans to > announce & source traffic from. Don't wildcard in customer prefix-lists > inbound. Every source packet address received "should" be covered by > his prefix-list (even if not the FIB entry best path choice). Every > other source IP address packet is dropped. In fantasy land, uRPF > "could" confirm that each packet source address matches at least one of > the networks in the prefix-list. Well, I could see having a safety-net of denies at the top built-in, since you wouldn't necessarily want your customer to register things like rfc1918, your aggregates, or long prefixes. This would lead to optimzing with deny 0.0.0.0/0 ge 25 (or whatever you consider too long). I agree that it would be nice, but I don't see it happening. > > Yes, I think there are definitely legitimate reasons why a customer > > would source traffic from prefixes where the actively selected route > > does not point back at the interface. This is why acl exceptions and > > the loose match came to be. With customers, the acl exception is > > probably appropriate. > > Would you agree it is indeed necessary for every BGP customer-facing > interface to implement exception checking with strict uRPF? > Customer-set communities can change local pref easily enough to break > strict uRPF lacking exception checking. But with the ACL permitting > exceptions based upon every possible network customer may be sourcing > from, the entry doesn't even have to be best path in the FIB to permit > the packet. Customer needed only to have gotten the ISP to include it > in his prefix-list at some point. It may not be necessary, but it is (imho) advisable, for the reasons you mention. Other, general cases would be multi-homed static customers, where you may statically route an aggregate to all locations, and route smaller chunks to individual locations. Others would be specific cases, based upon combined customer/provider needs. If a BGP customer was providing transit to others, and actively doing RPF checks themselves (and you trust them) I could see just doing loose checks against them.
|