Re: Securing EBGP while getting rid of big IRR-based prefix-list-filters (Was: How long AS-PATH policies have you used)

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

Hi.

I recently tried a setup where a pair of IRRd servers were linked with
Juniper routers via RTR protocol. Both servers were running IRRd (by
Reliably Coded), rpki-client (by OpenBSD Project), RTRTR (by NLnet
Labs) and a custom script [1] which dumped the IRR route objects from
IRRd database to JSON file for RTRTR. In short, the IRRd servers were
mirroring pretty much the same sources for "route", "route6" and
"as-set" RPSL objects as rr.ntt.net (default IRR server of bgpq4) and,
similarly to rr.ntt.net, used RPKI ROAs to overwrite or create
pseudo-IRR route objects [2] by reading the rpki-client JSON output
(/var/lib/rpki-client/json). What was different from the rr.ntt.net is
that authoritative IRR databases had a higher route object preference
[3] than third-party IRR databases, that is, a route object from a
third-party database like RADB or ALTDB is streamed to routers RTR
database only if it is not invalidated by RPKI ROA and there is no
overlapping route object in RIR-operated IRR database.

BGP import filters lists in routers were configured like this:

[ AS64511-in-exceptions-v6 origins:AS64511:AS-ALL irr-check ... ]

"origins:AS64511:AS-ALL" ensures that the origin AS numbers are in the
customer cone. It utilizes Junos regex-free "as-list-group" [4, 5]
feature and is built based on IRR as-set objects. "irr-check" policy
validates the routes against RTR database (aka named validation
database) named "irr":

root@isp-a> show configuration policy-options policy-statement irr-check
term reject-irr-invalid {
    from {
        protocol bgp;
        validation-database-instance {
            /* irr db contains '0.0.0.0/0-32 AS 0' and '::/0-128 AS 0'
entries */
            database-name irr;
            state invalid;
        }
    }
    then {
        validation-state invalid;
        reject;
    }
}
term mark-irr-valid {
    from {
        protocol bgp;
        validation-database-instance {
            database-name irr;
            state valid;
        }
    }
    then {
        validation-state valid;
        next policy;
    }
}
/* fallback if IRR RTR sessions are down */
term skip-irr-unknown {
    from {
        protocol bgp;
        validation-database-instance {
            database-name irr;
            state unknown;
        }
    }
    then {
        validation-state unknown;
        next policy;
    }
}
then next policy;

root@isp-a>


As seen above, as long as the RTR sessions with IRRd servers are up,
then prefixes can either be "invalid" or "valid".

Rest of the filters in filters list are typical bogon address and AS
numbers checks, RTBH related checks, prefix length checks, own
networks and IX networks checks, etc. Also the vanilla RPKI ROAs
check:

root@isp-a> 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;
    }
}
then next policy;

root@isp-a>

The default validation database used by the "rpki-check" policy is
populated by different pair of servers running Routinator 3000 (by
NLnet Labs), that is, it is completely separate from this IRRd setup.

It's also worth noting that as most of the IRR sources provide Near
Real Time Mirroring access, then changes to route objects in IRR can
propagate to routers RTR databases relatively quickly compared to
periodically pushing prefix-lists-filters to routers configuration.


Perhaps other vendors [6] would also like to implement the support for
multiple/named RTR databases feature? Support for so-called default
RTR database is nowadays anyway ubiquitous.


[1] https://gist.github.com/tonusoo/8d38c6e4014c57ef5543a7b6142cf1af
[2] https://irrd.readthedocs.io/en/stable/admins/rpki/
[3] https://irrd.readthedocs.io/en/stable/admins/route-object-preference/
[4] 
https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/topic-map/Improve-as-path-lookup.html
[5] example routing policy using the "as-list-group" was linked by
Saku Ytti in https://lists.nanog.org/archives/list/nanog () lists nanog org/thread/O5XX6BHOSMINX4HKT2SMVOI66SMYXFOR/
thread: https://p.ip.fi/hHia
[6] Saku Ytti mentioned requesting this from Nokia in "RTBH Support
Across the Industry" thread:
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/GCSARPWCT52FZRWIXD6MTHKMH5AIML5N/


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