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@internet2.edu
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Example: AS-REANNZ-MEMBERS => AS38022,AS38299,... (used for commodity) AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,... (used for NREN)
My second thought, where do we record our AS-SET's and other objects? We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
Dylan
________________________________ From: Steven Wallace ssw@internet2.edu Sent: Wednesday, 27 March 2024 2:22 AM To: routing-wg@lists.gna-g.net routing-wg@lists.gna-g.net Cc: Paul Howell phowell@internet2.edu; Ryan Harden rharden@internet2.edu; Jeff Bartig jbartig@internet2.edu; Chris Wilkinson cwilkinson@internet2.edu Subject: [Routing-wg] looking at published customer cones vs. ground truth..
[You don't often get email from ssw@internet2.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
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@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
Hi,
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Whilst we (Janet, AS786) are largely a leaf network off GEANT for these purposes (though with some exceptions related to DDoS protection and islands connected off islands), we do have a few AS-SETs that we use to cope with these differences.
AS-JANETUS (named from when we had a PoP in New York many moons ago) is used for our transit providers. AS-JANETPLUS is used for our commercial peers. AS-JANETEURO is used for GEANT/R&E.
We put AS-JANETPLUS in PeeringDB on the basis that is largely used by potential peers, and our AS786 aut-num object describes the routing policy with transit and GEANT.
Cheers, Rob
On 26 Mar 2024, at 23:38, Dylan Hall wrote:
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Example: AS-REANNZ-MEMBERS => AS38022,AS38299,... (used for commodity) AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,... (used for NREN)
My second thought, where do we record our AS-SET's and other objects? We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
Dylan
One possibility would be to use the export field on the aut-num to designate which as-set to use, as Rob Evans describes. For example: export to:AS11537 AS-CONE-THAT-INCLUDES-RE-TRANSIT
Another option would be for the global R&E community to maintain a common list of as-set to use. Perhaps there are other options?
I have the same thoughts concerning encouraging Internet2 downstream to create/maintain ROAs.
Steve
It may be helpful to adopt a standard naming convention for as-sets that represent an NREN’s customers Plus NREN transit. Perhaps a standard suffix like “NREN-TRANSIT”.
AS-NAME-ENDING-WITH-NREN-TRANSIT
On 27 Mar 2024, at 7:48, Steven Wallace wrote:
On 26 Mar 2024, at 23:38, Dylan Hall wrote:
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Example: AS-REANNZ-MEMBERS => AS38022,AS38299,... (used for commodity) AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,... (used for NREN)
My second thought, where do we record our AS-SET's and other objects? We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
Dylan
One possibility would be to use the export field on the aut-num to designate which as-set to use, as Rob Evans describes. For example: export to:AS11537 AS-CONE-THAT-INCLUDES-RE-TRANSIT
Another option would be for the global R&E community to maintain a common list of as-set to use. Perhaps there are other options?
I have the same thoughts concerning encouraging Internet2 downstream to create/maintain ROAs.
Steve
Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
That seems like an elegant solution.
I was thinking about automating the building of filters. Describing the objects in a notes field or an aut-num object I assume would need a human to interpret.
Looking up peeringdb, testing if they have a "-NREN-TRANSIT" version of their AS-SET, using that if it exists, otherwise fall back on the value listed in peeringdb should be fairly simple.
Dylan ________________________________ From: Steven Wallace ssw@internet2.edu Sent: Thursday, 28 March 2024 1:01 AM To: Dylan Hall dylan.hall@reannz.co.nz; routing-wg@lists.gna-g.net routing-wg@lists.gna-g.net Cc: Paul Howell phowell@internet2.edu; Ryan Harden rharden@internet2.edu; Jeff Bartig jbartig@internet2.edu; Chris Wilkinson cwilkinson@internet2.edu Subject: Re: [Routing-wg] looking at published customer cones vs. ground truth..
[You don't often get email from ssw@internet2.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
It may be helpful to adopt a standard naming convention for as-sets that represent an NREN’s customers Plus NREN transit. Perhaps a standard suffix like “NREN-TRANSIT”.
AS-NAME-ENDING-WITH-NREN-TRANSIT
On 27 Mar 2024, at 7:48, Steven Wallace wrote:
On 26 Mar 2024, at 23:38, Dylan Hall wrote:
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Example: AS-REANNZ-MEMBERS => AS38022,AS38299,... (used for commodity) AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,... (used for NREN)
My second thought, where do we record our AS-SET's and other objects? We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
Dylan
One possibility would be to use the export field on the aut-num to designate which as-set to use, as Rob Evans describes. For example: export to:AS11537 AS-CONE-THAT-INCLUDES-RE-TRANSIT
Another option would be for the global R&E community to maintain a common list of as-set to use. Perhaps there are other options?
I have the same thoughts concerning encouraging Internet2 downstream to create/maintain ROAs.
Steve
Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
Hi,
I was thinking about automating the building of filters. Describing the objects in a notes field or an aut-num object I assume would need a human to interpret.
I might have the wrong end of the stick here, but a human wouldn’t need to interpret an aut-num object as the policy would be expressed in RPSL.
E.g.
aut-num: AS786 as-name: JANET … import: from AS20965 action pref=50; accept AS-GEANTNRN export: to AS20965 announce AS-JANETEURO
The above is very basic RPSL of course, it can get a lot more complicated…
Cheers, Rob
Thus spake Rob Evans (Rob.Evans@jisc.ac.uk) on Thu, Mar 28, 2024 at 01:47:12PM +0000:
Hi,
I was thinking about automating the building of filters. Describing the objects in a notes field or an aut-num object I assume would need a human to interpret.
I might have the wrong end of the stick here, but a human wouldn´t need to interpret an aut-num object as the policy would be expressed in RPSL.
E.g.
aut-num: AS786 as-name: JANET ... import: from AS20965 action pref=50; accept AS-GEANTNRN export: to AS20965 announce AS-JANETEURO
The above is very basic RPSL of course, it can get a lot more complicated...
I think I missed this whole email thread when I was out for spring break. As folks have noticed here, notably PeeringDB only allows one IRR object to be specified. This also allows the majority of the Internet to ignore the chore of parsing any RPSL.
In RPSL as some have suggested, it is technically possible to document and programatically use specific AS-SETs in export/mp-export statements. However to my understanding there is exactly one implementation of this part of RPSL, and it has been abandoned long ago (irrtoolset). Even if it were maintained, rtconfig is still rather impractical to use, but at least the C code exists if someone wanted to pick that up and part out the "@rtconfig import <ASN-1> <rtr-1> <ASN-2> <rtr-2>" command to feed into something like bgpq4.
Or, If we were to agree on a tightly specified subset of RPSL, this parsing could be made substantially easier and implementable via a basic regex match. This might strongly be worth considering. Consider the above example, if we only allow the syntax "to AS65535 announce AS-FOO" this becomes pretty trivial.
Lastly as to where to put this data, starting in the EU there is a looming timeframe that non-authoritative IRR databases will all be deprecated. All objects will need to be in the appropriate RIR's system or they will be ignored. (of course, all of ESnet's objects are in RADb today, as we maintain proxy objects for all downstream networks) This is a looming problem, but it is separable from the above.
Dale
Back in the darkness of time when I was at AARNet I used RPSL hierarchically named AS sets, eg AS7575:AS-CUSTOMER, AS7575:AS-PEER, AS7575:AS-RESEARCH, to collect together the ASNs of those categories of peer ASes. That was mainly used to describe the policy in the aut-num object rather than produce filters as I used community tags for export of routes. You could use the comments field of the aut-num object to describe any peer sets you maintain.
Mark.
On 27/3/2024 10:38, Dylan Hall wrote:
At REANNZ we maintain an AS-SET with all our customers. We use this for commodity peering, transit, etc and this is recorded in peeringdb. However, it doesn't include NREN transit/backup. I don't really want to add NREN transit to that AS-SET as I have no intention of announcing those prefixes to my commodity peers and not including them provides some protection against making a mistake and leaking them.
What I would like to do is maintain a second AS-SET that points to my regular AS-SET as well as the list of NREN AS or AS-SETs I might provide transit to. The problem I see is where to record this? Peeringdb doesn't have a suitable field other than notes.
Example: AS-REANNZ-MEMBERS => AS38022,AS38299,... (used for commodity) AS-REANNZ-NREN => AS-REANNZ-MEMBERS,AS7575:AS-CUSTOMER,AS6360,... (used for NREN)
My second thought, where do we record our AS-SET's and other objects? We currently use RADB because I can create proxy records for my customers who don't generally do a great job of maintaining their own records in APNIC. That said, if I want to push them towards using RPKI they'll need to use APNIC, so maybe the answer isn't to rely on RADB.
Dylan
*From:* Steven Wallace ssw@internet2.edu *Sent:* Wednesday, 27 March 2024 2:22 AM *To:* routing-wg@lists.gna-g.net routing-wg@lists.gna-g.net *Cc:* Paul Howell phowell@internet2.edu; Ryan Harden rharden@internet2.edu; Jeff Bartig jbartig@internet2.edu; Chris Wilkinson cwilkinson@internet2.edu *Subject:* [Routing-wg] looking at published customer cones vs. ground truth.. [You don't often get email from ssw@internet2.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification https://aka.ms/LearnAboutSenderIdentification ]
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@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
-
Dale W. Carder -
Dylan Hall -
Mark Prior -
Rob Evans -
Steven Wallace