Re: How to validate blackhole routes? (Was: trouble letting go of IRR)

[Martin Tonusoo via NANOG <nanog () lists nanog org>]

Hi.

> 2. Perform originAS-only route validation for RTBH routes specifically,
> where the well-known BLACKHOLE [2] community must be present on the routes.
> Any widely-adopted RTBH filtering solution that ignores maxLength and
> relies only on originAS MUST require the BLACKHOLE community be attached.
> Everyone is leveraging that community by now, right? :)

I put together a setup where a router had a separate BMP session for
BGP groups related to IP transit customers, that is, the BMP
monitoring station received route monitoring messages only for
prefixes which were from adj-RIB-in tables of IP transit customers.
For example, Junos supports such BMP setup.

On BMP monitoring station I had a Rotonda(by NLnet Labs) running which
installed the prefixes to its RIB if they were allowed by Roto filter.
The Roto filter allowed only /32 v4 and /128 v6 prefixes and either if
they had RTBH community attached or they were withdrawals.

On the same BMP station there was a Routinator 3000(by NLnet Labs)
running and a small daemon which fetched the prefixes from Rotonda RIB
using its API, validated that origin ASN of the prefix matches the
covering VRP in Routinator using its API and finally wrote the
validated prefixes atomically to a JSON file.

This JSON file was read by RTRTR(by NLnet Labs) daemon every second
and updates were pushed to router using the RTR protocol. Router had a
separate RTR session for RTBH routes with RTRTR besides regular
sessions with Routinator 3000.

Rotonda, Routinator 3000, RTRTR and custom daemon were all running in
the same host. Corresponding validation records for RTBH routes
advertised by IP transit customer appeared in the router's validation
database within few seconds.

None of the import policies in router was changed, but the order of
policies in import policies list was modified. The RTBH check was
moved after the RPKI check. RPKI check policy in Junos can be seen
below:

root@vjr-17> show configuration policy-options policy-statement rpki-check
term reject-rpki-invalid {
    from {
        protocol bgp;
        validation-database invalid;
    }
    then {
        validation-state invalid;
        reject;
    }
}
term mark-rpki-valid {
    from {
        protocol bgp;
        validation-database valid;
    }
    then {
        validation-state valid;
        next policy;
    }
}
term skip-rpki-unknown {
    from {
        protocol bgp;
        validation-database unknown;
    }
    then {
        validation-state unknown;
        next policy;
    }
}

root@vjr-17>


I haven't tested it thoroughly, but in principle something like this
should work too.


Martin
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/SD2LIETZEKVRUOUTR3GLXIGAVQJZLI6O/