On Apr 6, 2020, at 6:46 PM, Richard Laager <[log in to unmask]> wrote:

On 4/6/20 6:38 PM, Andrew Hoyos wrote:
[log in to unmask]" class="">
On Apr 6, 2020, at 5:25 PM, Richard Laager <[log in to unmask]> wrote:

On 4/6/20 5:17 PM, Andrew Hoyos wrote:
This came up in two different conversations in June and January (per
mice-discuss archives)
I think the concern here is that the route servers aren’t doing IRR
filtering of members yet.
I agree 100% with the approach below, but with one caveat - we need to
be filtering members on the route servers first via IRR.
Otherwise, nothing preventing a member from advertising a /32 tagged
with a blackhole community of 8.8.8.8, or another member’s IP address.

Nothing is stopping me from announcing 8.8.8.0/24 right now, right?

I agree, that’s true in the current scenario. Nothing preventing you from doing that towards the route servers.

As it stands right now, though, we wouldn’t necessarily have to accept that route, and we’d have local control to reject/block or filter your ASN, drop RPKI invalid prefixes, etc, and to react as we please (ie: operational processes to fix the issue without reliance on MICE intervention, and without completely dropping our route server sessions). 

Or perhaps folks are already doing self-generated prefix lists and actions towards route server prefixes already (we, for example, passively keep an eye on ASNs/IRR data vs routes learned from MICE route servers).

In short, we’ve got tools to deal, if you do.
...
[log in to unmask]" class="">
In the case we enable a RTBH community without strict filtering, we’ve taken the control out of the members hands, and put a powerful tool in any members hands with no regard to security.

I'm still not understanding the difference between someone originating 8.8.8.0/24 and 8.8.8.8/32+65535:666. In either case (with blackholing support added), the route server will accept and propagate that to route server users. Whether they choose to accept that announcement is up to them the same either way.

Note that announcements to the route server do not directly result in blackholing traffic across the fabric. It simply sets a special next-hop.* If a participant chooses to accept that BGP route and route traffic to that next-hop*, only then will the traffic will be eaten. To put a finer point on this: if someone does not use the route servers, this change does not affect them in any way no matter what anyone announces as a blackhole route to the route servers.

Ack, thanks. Perhaps I misunderstood intent of actually dropping in flight traffic on switch fabric - this makes more sense and lessens my concern.

Still think we should get IRR filtering in place first.




To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1