1:22 p.m.
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
3:38 a.m.
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(a)internet2.edu>
Sent: Wednesday, 27 March 2024 2:22 AM
To: routing-wg(a)lists.gna-g.net <routing-wg(a)lists.gna-g.net>
Cc: Paul Howell <phowell(a)internet2.edu>; Ryan Harden <rharden(a)internet2.edu>;
Jeff Bartig <jbartig(a)internet2.edu>; Chris Wilkinson
<cwilkinson(a)internet2.edu>
Subject: [Routing-wg] looking at published customer cones vs. ground truth..
[You don't often get email from ssw(a)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(a)internet2.edu
_______________________________________________
Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
10:59 a.m.
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
11:48 a.m.
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
12:01 p.m.
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(a)lists.gna-g.net
> To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
9:36 p.m.
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(a)internet2.edu>
Sent: Thursday, 28 March 2024 1:01 AM
To: Dylan Hall <dylan.hall(a)reannz.co.nz>; routing-wg(a)lists.gna-g.net
<routing-wg(a)lists.gna-g.net>
Cc: Paul Howell <phowell(a)internet2.edu>; Ryan Harden <rharden(a)internet2.edu>;
Jeff Bartig <jbartig(a)internet2.edu>; Chris Wilkinson
<cwilkinson(a)internet2.edu>
Subject: Re: [Routing-wg] looking at published customer cones vs. ground truth..
[You don't often get email from ssw(a)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(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
1:47 p.m.
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
10:46 p.m.
Thus spake Rob Evans (Rob.Evans(a)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
1:29 p.m.
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(a)internet2.edu>
*Sent:* Wednesday, 27 March 2024 2:22 AM
*To:* routing-wg(a)lists.gna-g.net <routing-wg(a)lists.gna-g.net>
*Cc:* Paul Howell <phowell(a)internet2.edu>; Ryan Harden
<rharden(a)internet2.edu>; Jeff Bartig <jbartig(a)internet2.edu>; Chris
Wilkinson <cwilkinson(a)internet2.edu>
*Subject:* [Routing-wg] looking at published customer cones vs. ground
truth..
[You don't often get email from ssw(a)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(a)internet2.edu
_______________________________________________
Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
_______________________________________________
Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
353
days inactive
373
days old
8 comments
5 participants
participants (5)
-
Dale W. Carder -
Dylan Hall -
Mark Prior -
Rob Evans -
Steven Wallace