Request comment: list of IPs to block outbound

Sat Oct 19 07:11:55 UTC 2019

On Fri, 18 Oct 2019 at 23:45, Lukas Tribus <lists at ltri.eu> wrote:

Hey Lukas,

> I'm saying this breaks valid configurations because even with textbook
> IRR registrations there is a race condition between the IRR
> registration (not a route-object, but a new AS in the AS-MACRO), the
> ACL update and the BGP turn-up of a new customer (on AS further down).

I'm not proposing an answer, I'm asking a question.
Could it be that the utter disinterest in working BGP filters is
consequence of it not actually mattering in turn-ups in typical case?
And would the examples be same, if we were not so disinterested in
having proper BGP filters in place?
If in common case we did ACL, would we evolve different mechanisms to
ensure correctness of filtering before fact? Perhaps common API to
query state of filters in provider networks? Perhaps maintenance
window to turn-up new transit with option to fall back immediately and
complain about their configurations?

> Is this deployed like this in a production transit network? How does
> this network handle a failure like in example 2? How does it
> downstream customers handle the race conditions like in example 1?

Yes, I've ran BGP prefix-list == firewall filter (same prefix-list
verbatim referred in BGP and Firewall) for all transit customers in
one network for +decade. Few problems were had, the majority of
customers were happy after explaining them logic behind it. But this
was tier2 in Europe, data quality is high in Europe compared to other
markets, so it doesn't communicate much of global state of affairs. I
would not feel comfortable doing something like this in Tier1 for
US+Asia markets.
But there is also no particular reason why we couldn't get there, if
we as a community decided it is what we want, it would fix not just
unexpected BGP filter outages but also several dos and security
issues, due to killing spoofing. It would give us incentive to do BGP
filtering properly.

-- 
  ++ytti