Greetings,
Internet2 doesn’t explicitly filter routes it receives from NREN peers. It does apply standard sanity checks, but all legitimate routes are accepted. It is common practice among NRENs to exchange their customers’ routes AND routes heard from other NRENs. Internally, we sometimes refer to the entire collection of NREN routes as ITN (International Transit Network). This practice of offering mutual transit has served the NREN community by providing redundancy and allowing for more sparse interconnection points. For example, Internet2 becomes a transit AS interconnecting networks that land on the east and west coasts of the US.
However, not explicitly filtering routes among the NRENs has downsides. Last week, an NREN unintentionally announced many non-NREN routes to Internet2. The number of routes announced triggered a shutdown of the BGP session, and the increase in Internet2’s route table size caused a network in the US to shut down its peering with Internet2. Explicitly filtering routes received from our NREN peer would have mitigated this incident.
Building a filter based on a peer’s as-cone could be a reasonable standard practice to improve routing security if NRENs only exchanged their customer routes. An approach that might fit our needs better could include a published as-set representing the customer as-cone for each NREN, plus the RPSL (I’m not an RPSL expert, but I assume this is possible) needed to convey which customer and transit routes to accept from a peer.
Another approach might be to maintain an as-cone for the entire ITN, and use that as the basis for a filter. There are approximately 2,600 ASs in the ITN.
I’m not a BGP expert, but I’d like to support a conversation among the NRENs to explore options and, potentially, to recommend best practices to improve our collective routing security while maintaining our transit policies.
I’ve generated some data to spark the conversation. Firstly, I need to say that if Internet2 were in this list, it would show “No AS-SET for Internet2 (AS11537).” We’re reluctant to publish such an as-set as there isn’t a well-understood interpretation of how it would be used among NRENs. If Internet2 published its as-cone via an as-set, would other networks apply prefix filters based on this as-set and reject routes from the other NRENs that are part of the ITN?
Based on routing data from bgp.nsrc.org and sources like the IRRs and peeringdb, here’s a list of NRENs that peer with Internet2, their as-set, and the count of ASs received that fall outside of the as-set.
I’m sure I’ve made errors. Please let me know if you see anything in error.
Steve
AARNET (AS7575) as-set="AS7575:AS-CUSTOMER" count of origins outside customer cone 1 out of 96 origins seen.
list of origins outside customer cone [10906]
AMPATH (AS20080) as-set="AS-AS20080-TRANSIT" count of origins outside customer cone 6 out of 23 origins seen.
list of origins outside customer cone [28609, 263076, 262441, 19611, 27676, 263358]
ANKABUT (AS47862) as-set="AS47862" count of origins outside customer cone 9 out of 9 origins seen.
list of origins outside customer cone [59968, 50602, 58283, 51182, 61137, 47862, 57143, 52216, 50811]
No AS-SET for APAN (AS7660)
CANARIE (AS6509) as-set="AS6509:AS-CANARIE" count of origins outside customer cone 1 out of 150 origins seen.
list of origins outside customer cone [577]
CEDIA (AS61468) as-set="AS61468:AS-CEDIATRANSITMIEMBROS" count of origins outside customer cone 3 out of 16 origins seen.
list of origins outside customer cone [27947, 22724, 61468]
CERN (AS513) as-set="AS-CERNEXT" count of origins outside customer cone 0 out of 0 origins seen.
CERNET (AS23911) as-set="AS4538:AS-CUSTOMERS-V6" count of origins outside customer cone 0 out of 0 origins seen.
CSTNET (AS7497) as-set="AS7497:AS-CUSTOMERS" count of origins outside customer cone 0 out of 1 origins seen.
No AS-SET for CUDI (AS18592)
No AS-SET for CUDI (AS28569)
No AS-SET for ENSTINET (AS6879)
GEANT (AS20965) as-set="AS-GEANTNRN" count of origins outside customer cone 57 out of 533 origins seen.
list of origins outside customer cone [38272, 138369, 138371, 327944, 138378, 327947, 328076, 12812, 328212, 24348, 37661, 24349, 24350, 328224, 328353, 24352, 24353, 24355, 24357, 24358, 37288, 24361, 24362, 24363, 24364, 328752, 24369, 24370, 24371, 327992, 4538, 199354, 329410, 328647, 328648, 328903, 209098, 132553, 11340, 6736, 37074, 328530, 37717, 328662, 328663, 133465, 8670, 49248, 133475, 23910, 21612, 329326, 328054, 328439, 328184, 328702, 24575]
No AS-SET for GOREX (AS35889)
No AS-SET for HBKU (AS34945)
No AS-SET for JGNX (AS17934)
KACST (AS8895) as-set="RIPE::AS8895:AS-KACST" count of origins outside customer cone 0 out of 7 origins seen.
KREONET2 (AS17579) as-set="AS1237:AS-KREONET" count of origins outside customer cone 0 out of 36 origins seen.
No AS-SET for NEAAR (AS396390)
NKN (AS9885) as-set="AS-NIC-NKN-BGP-PEERS" count of origins outside customer cone 2 out of 106 origins seen.
list of origins outside customer cone [152576, 132124]
NORDUNET (AS2603) as-set="AS-NORDUNET" count of origins outside customer cone 3 out of 154 origins seen.
list of origins outside customer cone [200264, 9113, 48670]
OMREN (AS206350) as-set="AS206350" count of origins outside customer cone 2 out of 2 origins seen.
list of origins outside customer cone [28885, 206350]
QFN (AS29384) as-set="AS29384" count of origins outside customer cone 1 out of 1 origins seen.
list of origins outside customer cone [29384]
REANNZ (AS38022) as-set="RADB::AS-REANNZ-MEMBERS" count of origins outside customer cone 1 out of 32 origins seen.
list of origins outside customer cone [3477]
REDCLARA (AS27750) as-set="AS27750:AS-MEMBERS" count of origins outside customer cone 37 out of 41 origins seen.
list of origins outside customer cone [52224, 263683, 262156, 27790, 263186, 264724, 265884, 61476, 28068, 263204, 4270, 61486, 10671, 264630, 61496, 5692, 263235, 52424, 28107, 27981, 28109, 264785, 270033, 27993, 52442, 52314, 264798, 20191, 27875, 265700, 23140, 27750, 27883, 264687, 26610, 27897, 27770]
RNP (AS1916) as-set="RADB::AS-RNP" count of origins outside customer cone 4 out of 79 origins seen.
list of origins outside customer cone [268744, 61612, 28157, 28222]
SINET (AS2907) as-set="JPIRR::as2907:as-sinet" count of origins outside customer cone 26 out of 122 origins seen.
list of origins outside customer cone [1921, 18183, 38296, 7577, 7588, 9264, 7472, 17713, 7610, 4538, 4158, 63555, 45259, 3662, 24151, 11096, 7650, 17764, 24302, 38254, 7539, 18422, 137207, 1659, 3836, 4605]
No AS-SET for SINGAREN (AS23864)
No AS-SET for STARLIGHT (AS10764)
SURFNET (AS1103) as-set="AS-SURFNET" count of origins outside customer cone 0 out of 25 origins seen.
TENET (AS2018) as-set="AS-TERTIARY" count of origins outside customer cone 0 out of 5 origins seen.
No AS-SET for TRANSPAC (AS22388)
TWAREN (AS7539) as-set="AS7539:AS-TWAREN" count of origins outside customer cone 0 out of 8 origins seen.
UBUNTUNET (AS36944) as-set="AS-UBUNTUNET" count of origins outside customer cone 1 out of 21 origins seen.
list of origins outside customer cone [327945]
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu
On Wed, Apr 3, 2024 at 8:50 AM Mark Prior <mrp(a)mrp.net> wrote:
> On 3/4/2024 20:37, Michael Lambert wrote:
> >> On 2 Apr 2024, at 16:24, David Farmer <farmer(a)umn.edu> wrote:
> >>
> >> I had a thought.
> >>
> >> Does GREN or GNA-G have an ASN?
> >> If not we/it could probably get one.
> >>
> >> My suggestion would be to use that ASN for a set of globally agreed to
> communities and to create an as-set that represents the entirety of the
> Global NREN community.
> >
> > I have to admit I have philosophical issues with the idea of obtaining
> an ASN just to use in tagging without any real plans for having it appear
> in an AS path in the routing table.
> >
>
> Well it does provide uniqueness, and there are plenty of assigned ASN
> not in the routing table..
>
> Mark.
>
There are alternatives, but I don't think they are any more palatable;
- We could choose a private ASN and overload it with our specifications. We
would need to ensure the communities were stripped when leaving the Global
R&E community since uniqueness isn't guaranteed.
- We could register well-known BGP communities with IANA, using the first
come, first serve range specified RFC1997.
https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-…
Those options only work for BGP communities. We really shouldn't use
private use or other reserved ASNs in the IRR.
However, now that we have 32-bit ASNs, they really aren't a limited
resource anymore. A registered ASN is the right answer, in my opinion.
Thanks.
--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
https://docs.google.com/document/d/1hKCo75qrC_21TdlQULCTgA5ApFCgBTSPo7tecgD…
