Hi Gert,
On 3/27/14, Gert Doering <[email protected]> wrote:
> Hi,
>
> On Thu, Mar 27, 2014 at 10:42:23AM -0400, Lee wrote:
>> And to ratchet the level of hyperbole down a notch, enabling uRPF can lead
>> to
>> - not being able to specifically ping one particular interface from
>> the management system
>> - not having traceroute tell me on which exact path my packets are
>> flowing
>> - NMS/discovery limitations
>> and yet enabling uRPF is generally considered A Good Idea.
>
> 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? 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.
> 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.
Lee
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
