RE: Request comment: list of IPs to block outbound

[<adamv0025 () netconsultings com>]

> -----Original Message-----
> From: NANOG <nanog-bounces () nanog org> On Behalf Of Lukas Tribus
> Sent: Friday, October 18, 2019 9:45 PM
> To: Saku Ytti <saku () ytti fi>
> Cc: nanog () nanog org
> Subject: Re: Request comment: list of IPs to block outbound
>
> Hello,
>
> On Fri, Oct 18, 2019 at 7:40 PM Saku Ytti <saku () ytti fi> wrote:
> > It's interesting to also think, when is good time to break things.
> >
> > CustomerA buys transit from ProviderB and ProviderA
> >
> > CustomerA gets new prefix, but does not appropriately register it.
> >
> > ProviderB doesn't filter anything, so it works. ProviderA does filter
> > and does not accept this new prefix. Neither Provider has ACL.
> >
> >
> > Some time passes, and ProviderB connection goes down, the new prefix,
> > which is now old prefix experiences total outage. CustomerA is not
> > happy.
> >
> >
> > Would it have been better, if ProviderA would have ACLd the traffic
> > from CustomerA? Forcing the problem to be evident when the prefix is
> > young and not in production. Or was it better that it broke later on?
>
> That's an orthogonal problem and it's solution hopefully doesn't require a
> traffic impacting ingress ACL.
>
> 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).
>
>
> Here's a environment for the examples below:
>
> Customer C1 uses existing transits Provider P11 and P12 (meaning C1 is
> actually a production network; dropping traffic sourced by it in the DFZ is very
> bad; P11 and P12 is otherwise irrelevant).
> Customer C1 is about to turn-up a BGP session to Provider P13.
> Provider P13 is a Tier2 and buys transit from Tier1 Providers P1 and P2
> Provider P2 deploys ingress ACLs depending on IRR data, based on P13's AS-
> MACRO.
I still think that ACLs rule should go hand in hand with eBGP prefixes by default.  
But the ACLs should be updated based on advertised and accepted eBGP prefixes automatically (so not dependent on 
external data).
If the IRR data accuracy and AS-MACROs get solved the filtering problem would be solved as well.
If such mechanism was enabled by default in all vendors' implementations it would address the double lookup problem of 
uRPF while accomplishing the same thing and even address the source IP spoofing problem.
3 Simple rules:

Rule 1)
If you are advertising a prefix 
Then allow it as source prefix in your egress ACL
And allow it as destination prefix in you ingress ACL 
(cause why do you advertise a prefix well you expect to send traffic sourced from IPs covered by that prefix and you 
expect to get a response back right?)
And as a result
Traffic sourced from IPs haven't advertised via a particular link would be blocked at egress from your AS (on that 
link) -boundary A1
Traffic destined to IPs you haven't advertised via a particular link it will be blocked at ingress to you AS (on that 
link)  

Rule 2)
If you are accepting a prefix 
Then allow in as source in your ingress ACL 
And allow it as destination in your egress ACL
(cause why do you accept a prefix well you expect to send traffic towards IPs covered by that prefix and you'd want 
those IPs to be able to respond back right?) 
And as a result
Traffic sourced from IPs you haven't accepted via a particular link would be blocked at ingress to your AS (on that 
link) -boundary A2
Traffic destined to IPs you haven't accepted via a particular link would be blocked at egress from your AS (on that 
link) -required because there's already an egress ACL blocking everything.

Rule 3)
If interface can't be uniquely identified based on IPs used for the eBGP session warn the operator about the condition  

The obvious drawback especially for TCAM based systems is the scale, so not only we'd need to worry if our FIB can hold 
800k prefixes, but also if the filter memory can hold the same amount -in addition to whatever additional filtering 
we're doing at the edge (comb filters for DoS protection etc...)

adam