On 11/13/16 8:12 PM, Nick Hilliard wrote: > joel jaeggli wrote: >> The case where routine maintance creates temporary blackholes is >> basically ubiquitious were you attempting to use urp strict. > > oh indeed - I've been at the receiving end of exactly this type of > blackholing. Very annoying. But I just wonder if urpf is the best tool > to hammer this particular nail in. Sriram implicitly points out that > the term "customer cone" is a rather vague concept, and once you add the > vagaries of peering cones, it gets a lot worse. From an anecdotal point > of view, people route traffic all over the place, and the further you > get away from the traffic endpoints, the more difficult > source-validation filtering becomes. > > I suspect Sriram's proposed methodology is not going to be as useful as > it might seem in production networks because he's making an assumption > that the list of valid source paths can be built up by creating a union > of all source ASNs and applying that to the union of all interfaces > which are identified as feasible paths, intersected with the list of > interfaces with feasible path urpf enabled. Going back to his diagram, > what if AS1 announces a prefix over a different transit e.g. AS6, but > not AS4 or AS5? Then they issue traffic with a source address from that > prefix. The only way to handle this situation is with loose urpf, which > is a nice way of saying that enhanced urpf would cause breakage in this > situation.
Yeah, loose, ends up being the limit of was is feasible; you might as well deploy a bogon filter drop martians, and not bother. > I'm raising this because we run an as112 server at INEX and we've > observed a surprisingly large quantity of traffic directed towards the > anycast address from IP addresses from all over the world which come > over the IXP fabric, but which we can't imagine how it arrives there, > e.g. traffic from apnic + latam regions, etc. While I appreciate that > this is anecdotal, it's a real enough observation for me to suspect that > the level of decoupling between bgp announcements (i.e. return path > traffic) and forward path routing is something that would cause enhanced > urpf to cause blackholing on production networks. The preference of some networks to trump regional preference with free, to participate in mlpe exchages, without announcing routes on them, or to selectively announce routes only to certain participants, while witholding them from others makes all sort of wierd stuff appear there. it makes to hard or more likely impossible to apply such filtering on IXP ports. In our case, where we generate prefix list filters for all routes that we accept into the rib at exchange points we are naturally not even going to have all of the paths that may potentially be available there. > Nick >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
