On 3/28/14, Gert Doering <[email protected]> wrote: > Hi, > > On Fri, Mar 28, 2014 at 10:22:45AM -0400, Lee wrote: >> > Actually, enabling uRPF on core-to-core interfaces is considered a >> > significantly stupid idea. You enable uRPF towards your customers, >> > and loose(!) uRPF towards peers/upstreams for BGP-RTBH. >> >> Is there an RFC that spells it out that clearly? > > Well, I never searched. I find that so blindingly obvious that I never > assumed someone would want to do that, and not understand why it hurts.
Which is why I tried to summarize the caveats for this draft earlier. Sometimes it seems like the experts think something is so blindingly obvious they don't need to document it -- which leaves the non-experts to blindly follow "best practices" or learn the hard way. >> I couldn't find >> anything about 3 years ago when an auditor from our security office, >> using the CIS Secure IOS benchmark, decided that every router >> interface needed uRPF enabled. You want fun, try explaining >> asymmetrical routing to an auditor. > > Yeah, I can feel your pain. OTOH in certain situations there's not > much you can do except "call his supervisor, declare the auditor to > be defective, RMA". I tried that :) >> > None of these will impair traceroute or NMS/discovery. >> >> If you only do uRPF at the edge - right, it doesn't impair traceroute >> but it did give us grief with NMS/discovery: >> >> NMS 10.10.10.10 >> | >> core >> / \ >> / \ >> distA distB >> |10.1.1.3 | 10.1.1.4 >> | | >> --- access --- >> >> When the access layer switch says it's neighbors are 10.1.1.3 and >> 10.1.1.4 we had problems. Maybe it was just the discovery software >> being stupid, but we ended up putting every device into the discovery >> seed file. > > Mmmh. Unless something weird comes into play here, I can't see how > uRPF could interfere if none of the links you have shown (core<->dist<-> > access) has uRPF enabled... Sorry - I grabbed an old msg describing the problem and cut a bit too much. The access layer is an L2 switch so uRPF is enabled on the 10.1.1.3 and 10.1.1.4 interfaces at the distribution layer. The nms machine tries to ping 10.1.1.3 (or tries to discover 10.1.1.3 - same problem) The core router sees two equal cost paths to the 10.1.1 network. If core routes the packet to distB the unicast RPF check passes on distB (source addr 10.10.10.10 is routed via distB-core link) and distB forwards the packet over the 10.1.1 access network to distA. The RPF check fails on distA because the route to 10.10.10.10 is via the distA-core link, not via the 10.1.1 access network interface that the packet came in on. Lee _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
