Nick, My responses marked with [Sriram].
[Nick] 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. [Sriram] That description is confusing. The description I would provide is: The ISP's AS creates a union of all announced prefixes that have a common origin AS. Those announcements have potentially been received on various customer/ peer/ provider interfaces. Take that union of prefixes and include it in Reverse Path Filter (RPF) tables on all interfaces on which one or more of the prefixes in the union were announced. [Nick] 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. [Sriram] This (your) scenario still works with the above clarified description of the method. The bottom line is: Wherever feasible path uRPF method is used currently, the enhanced FP uRPF method would work and with greater robustness. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
