Request comment: list of IPs to block outbound

Lukas Tribus lists at ltri.eu
Fri Oct 18 17:15:42 UTC 2019


Hello!

On Tue, Oct 15, 2019 at 12:46 PM Saku Ytti <saku at ytti.fi> wrote:
>
> On Mon, 14 Oct 2019 at 09:30, Vincent Bernat <bernat at luffy.cx> wrote:
>
> > How much performance impact should we expect with uRPF?
>
> Depends on the platform, but often it's 2nd lookup. So potentially 50%
> decrease in performance. Some platforms it means FIB duplication. And
> ultimately it doesn't really offer anything over ACL, which is, in
> comparison, much cheaper feature.
> I would encourage people to toolise this, then the ACL generation is
> no cost or complexity. And you can use ACL for many BGP customers too,
> as you create 'perfect' prefix-list for customer, you can reference to
> same prefix-list in ACL, without actually needing customer to announce
> that prefix, as it's entirely valid to originate traffic from
> allowable prefix without advertising the prefix (to you).

This has the potential to brake things, because it requires symmetry
and perfect IRR accuracy. Just because the prefix would be rejected by
BGP does not mean there is not a legitimate announcement for it in the
DFZ (which is the exact difference between uRPF loose mode and the ACL
approach).

For BGP customers where I control the announced IP space (it's mine,
the customer has a private ASN and the only reason for BGP is so he
can multi-home to different nodes of my network), sure.

For real "IP Transit" where the customers may itself have multiple
downstream ASNs, there is no guarantee that everyone in the chain will
update the IRR records 24 - 48 hours before actually sourcing traffic
from a new prefix (or enabling that new downstream as-path). Some
other transit may just allow prefixes "manually" (for example, because
of LOA's or inetnum objects, as opposed to route objects), so *a valid
announcement is in the DFZ*, you are just not accepting it on your
customers BGP session.

In fact, maybe my downstream customer just wants to send traffic to my
network, but not receive any, so I don't actually have to include that
customer in my AS-macro (an exotic use-case for sure, just trying to
point out that there will always be asymmetry).

Routing, BGP and the IRR data is asymmetric by definition and neither
real-time nor 100% accurate. That's not a problem for BGP and strict
ingress prefix-lists, but it is a problem for ingress ACL'ing, because
the latter effectively blackholes traffic, while uRPF loose mode does
not (if there is a announcement for it in the DFZ).

So I don't think ACL's can replace uRPF loose mode in the DFZ and
frankly I find this proposal to be a bit dangerous.


If my transit provider would do this without telling me, I'm turning
up a new transit customer with an incomplete IRR record, causing an
immediate partial outage for them, I would be *very* surprised (along
with some other emotions).


cheers,
lukas



More information about the NANOG mailing list