Ingress filtering on transits, peers, and IX ports

Thu Oct 15 14:21:53 UTC 2020

We deploy urpf strict on all customer end-host and broadband circuits. In
this scenario urpf = ingress acl I don't have to think about.

We deploy urpf loose on all customer multihomed DIA circuits. I dont this
makes sense - ingress packet acl would be more sane.

Any flavour of urpf on upstream transit or peering would be challenging.
Ingress packet acl dropping source = own+customer prefix might make sense
depending on your AS topology.

You might argue that ingress packet acl would be operationally simpler on
customer and upstream, as you could cover all scenarios.

On Thu, Oct 15, 2020 at 10:05 AM Saku Ytti <saku at ytti.fi> wrote:

> On Thu, 15 Oct 2020 at 15:14, <adamv0025 at netconsultings.com> wrote:
>
>
> > Yes one should absolutely do that, but...
> > But considering to become a good netizen what is more work?
> > a) Testing and the enabling uRPF on every customer facing box or setting
> up precise ACLs on every customer facing port, and then maintaining all
> that?
> > b) Gathering  all your PAs (potentially PIs) (hint: show bgp nei x.x.x.x
> advertised routes) crafting an ACL and apply it on several peering/transit
> links?
> > One of them is couple of weeks work and one is an afternoon job.
>
> I am not fan of uRPF, expensive for what it does. But I don't view it
> as an alternative here, I view it as either adding an ACE on all
> egresses on egress direction or adding ACE on the ingress where
> customer is on ingress direction.
>
> To me these options seem equally complex but the latter one seems superior.
>
> --
>   ++ytti
>

-- 
Tim:>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201015/321dba3f/attachment.html>