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. 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. Nick _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
