> From: Saku Ytti <s...@ytti.fi> > Sent: Thursday, October 15, 2020 11:12 AM > > Hey, > Hey Saku,
> > All stub autonomous systems should have a simple egress ACL allowing > only PI of their customers and their own PAs -it’s a simple ACL at each > AS-Exit > points (towards transits/peers), that’s it. > > > > -not sure why this isn’t the first sentence in every BCP and “security > > bulletin”… > > I will venture a guess. > > 1) it's very specific scenario to be stubby and have downstream PI Yes it is and in most cases it's about "I have these few /XYs from which I address my customers (eyeballs) so nothing outside of these should ever leave my AS" -as simple as that. > 2) it won't address customers spoofing each other arbitrarily and > customer1 spoofing as customer2 on the internet, giving large chunk of the > utility of spoofing even with protection in place > Yes its not 100% effective as you pointed out, However if every stub AS implemented this egress ACL on the few of their transit/peering links, there would be a lot less inter-AS garbage floating around. > How do you maintain that ACL? Well you're gonna update the ACL every time you acquire a new PA space (every now and then), or when another customer wants you route their PI (rare, simply cause you're a stub AS with mostly eyeballs). It's one ACL you need to update on every box with AS-exit links -usually there are not that many in a stub-AS. > Why doesn't that same mechanism allow > ingress ACL on the customer port? Your proposal looks low utility for work > needed. > 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. adam
