On 4/6/20 6:38 PM, Andrew Hoyos wrote:
>
> 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.
...
> 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.
* I forgot to mention that we'll need something on the route servers
that will respond to ARP/ND requests for the blackhole IPs and return
the blackhole MAC.
--
Richard
