- Routing-wg - lists.nordu.net

Border Gateway Protocol Security and Resilience - NIST SP 800-189 Rev. 1 (Initial Public Draft)
by Alex Moura 05 Jan '25

05 Jan '25

Hi, Happy New Year! NIST SP 800-189 Rev. 1 (Initial Public Draft) Border Gateway Protocol Security and Resilience https://csrc.nist.gov/pubs/sp/800/189/r1/ipd Alex Classification: Internal

1 0

Routing Working Group October Meeting
by Meade, Brenna 14 Oct '24

14 Oct '24

Hi all, Please join the October Routing Working Group meeting. Oct 15, 2024 8 am EST / 12 pm UTC Zoom information below: Brenna Meade is inviting you to a scheduled Zoom@IU meeting. Join from computer or mobile: https://iu.zoom.us/j/88412839078 Meeting ID: 884 1283 9078 One tap mobile +17193594580,,88412839078# US +13462487799,,88412839078# US (Houston) Dial by your location +1 719 359 4580 US +1 346 248 7799 US (Houston) +1 669 444 9171 US +1 669 900 6833 US (San Jose) +1 253 205 0468 US +1 253 215 8782 US (Tacoma) +1 646 558 8656 US (New York) +1 646 931 3860 US +1 689 278 1000 US +1 301 715 8592 US (Washington DC) +1 305 224 1968 US +1 309 205 3325 US +1 312 626 6799 US (Chicago) +1 360 209 5623 US +1 386 347 5053 US +1 507 473 4847 US +1 564 217 2000 US Meeting ID: 884 1283 9078 IU videoconferencing equipment: 26 884 1283 9078 Videoconferencing equipment outside of IU: SIP: 88412839078(a)zoomcrc.com H.323: 162.255.37.11 (US West) 162.255.36.11 (US East) 221.122.88.195 (Mainland China) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 64.211.144.160 (Brazil) 159.124.132.243 (Mexico) 159.124.168.213 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 884 1283 9078 Zoom@IU Team | cthelp(a)iu.edu | https://kb.iu.edu/d/bfqu Brenna Meade Senior Network Architect, International Networks Program Director, WINS Indiana University

1 1

SC24 SCinet NRE Friday Meetings. - Apologies.
by Addleman, Hans C 10 Oct '24

10 Oct '24

Routing Working Group, Apologies for that mail about the SCinet / NRE calls. That was meant to go to a very similar email list and outlook helped me autocorrect the address. Please disregard! I do look forward to seeing many of you hopefully at SC24 in Atlanta! Thanks! Hans

1 0

SC24 SCinet NRE Friday Meetings.
by Addleman, Hans C 10 Oct '24

10 Oct '24

Greetings All, Reminder that our NRE SCinet/ Participants meeting is now meeting weekly and our next call is tomorrow. Please see attached calendar invite.

1 0

Internet2 TechEx BGP Workshops.
by Addleman, Hans C 27 Sep '24

27 Sep '24

Greetings Routing Working Group, Here is some information on the workshops that I mentioned on the call last night. Hope to see many of you at the conference! Internet2 Technology Exchange, Boston, Dec 9-13th - https://events.internet2.edu/website/69276/home/ Morning Workshop https://events.internet2.edu/website/69276/tutorials/#gateway This hands-on tutorial, organized by the University of South Carolina (USC), International Networks at Indiana University (IU), and the Engagement and Performance Operations Center (EPOC) will provide effective hands-on training on BGP, from concepts to real implementation, conducted in a safe, virtual environment. The tutorial will allow attendees to: 1. deploy internetworks composed of multiple ASs connected via BGP, running a production-grade BGP implementation; 2. manipulate BGP options and attributes without the fear of disruptions, thus enabling them to implement different policies; 3. acquire advanced BGP routing skills; and 4. familiarize with a platform that supports high-speed rates of 10 Gbps and above, using a real protocol stack implementation. Attendees will be provided with detailed laboratory manuals and a training platform, accessible from the Internet using a regular web browser (no SSH, Telnet, or other requirements). Access to the training platform will be granted for six months. Other advanced topics will include MPLS and Multi-protocol BGP. Afternoon Workshop https://events.internet2.edu/website/69276/tutorials/#bgp Good BGP route policy is essential for routing security and to ensure your network traffic is making the best use of your R&E network connectivity and peering. This hands-on tutorial will cover creating a complete BGP routing policy for your network and best practices for configuring BGP. We will also look at useful tools for troubleshooting BGP routing issues. Thanks, Hans

4 5

RWG September Meeting
by Meade, Brenna 23 Sep '24

23 Sep '24

Hi all, Please join the September Routing Working Group meeting. September 24, 2024 8 pm EST / 12 am UTC Zoom information below: Brenna Meade is inviting you to a scheduled Zoom@IU meeting. Join from computer or mobile: https://iu.zoom.us/j/87870975436 Meeting ID: 878 7097 5436 One tap mobile +17193594580,,87870975436# US +16699006833,,87870975436# US (San Jose) Dial by your location +1 719 359 4580 US +1 669 900 6833 US (San Jose) +1 253 205 0468 US +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 444 9171 US +1 646 931 3860 US +1 689 278 1000 US +1 301 715 8592 US (Washington DC) +1 305 224 1968 US +1 309 205 3325 US +1 312 626 6799 US (Chicago) +1 360 209 5623 US +1 386 347 5053 US +1 507 473 4847 US +1 564 217 2000 US +1 646 558 8656 US (New York) Meeting ID: 878 7097 5436 IU videoconferencing equipment: 26 878 7097 5436 Videoconferencing equipment outside of IU: SIP: 87870975436(a)zoomcrc.com H.323: 162.255.37.11 (US West) 162.255.36.11 (US East) 221.122.88.195 (Mainland China) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 64.211.144.160 (Brazil) 159.124.132.243 (Mexico) 159.124.168.213 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 878 7097 5436 Zoom@IU Team | cthelp(a)iu.edu | https://kb.iu.edu/d/bfqu Brenna Meade Senior Network Architect, International Networks Program Director, WINS Indiana University

1 1

Fw: [External] FW: AS-SETs for NRENs
by Meade, Brenna 05 Sep '24

05 Sep '24

Hi Routing Working Group, Please see information about the upcoming AS-SET for NRENs discussion provided by Internet2 Brenna Meade Senior Network Architect, International Networks Program Director, WINS Indiana University From: ssw(a)internet2.edu When: 5:00 PM - 6:00 PM October 10, 2024 Subject: AS-SETs for NRENs Title: Collective Action for NREN Routing SecurityJoin the Director of Routing Integrity, Steve Wallace, and Sr. Network Architect, Jeff Bartig, of Internet2 for a discussion on “Improving NREN Routing Security with AS-SET”.AS-SET is an IRR object used to publish the set of origin ASNs a network is expected to announce. Implementation of prefix filters based on AS-SETs ensure only accepted routes that are intended to be announced by a peer and limit the propagation of route leaks. The outcome would ensure global NREN routing stability.The objective of this presentation is to bring together the NREN community to ensure routing stability as a whole followed by a brief training on how AS-SET is usedAgenda: * Brief History of NREN peering policy * The challenges of NREN routing policy * Publishing routing policy to enable route filtering * What is an as-set * The role of as-sets to enable filter creation * Models for maintaining as-sets * Q&A Who this call is for: * Network architects and cybersecurity engineers. * NREN leaders and network managers. The presentation will be held two times to accommodate the community around the globe, once on Oct 9 from 8:00-9:00 PM UTC and again on Oct 11 from 12:00-1:00 AM UTC over Zoom to accommodate attendee timezones.If you have any questions, feel free to email Thomas Araneta at taraneta(a)internet2.edu<mailto:taraneta@internet2.edu>

1 0

Survey for Routing Working Group Members
by Meade, Brenna 14 May '24

14 May '24

HI Routing Working Group Members! We have created the following survey to understand more about the members of the group and what we should be focusing on going forward. If you get the chance feel fill out the following survey. Results will be discussed in upcoming RWG meetings. https://docs.google.com/forms/d/e/1FAIpQLSdGFRCADvT3AbNPI1dkQFURcboFtfzJCLS… <https://docs.google.com/forms/d/e/1FAIpQLSdGFRCADvT3AbNPI1dkQFURcboFtfzJCLS…> Brenna Meade Routing Working Group Co-Chair International Networks @ Indiana University

1 1

looking at published customer cones vs. ground truth..
by Steven Wallace 15 Apr '24

15 Apr '24

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

5 8

Re: crafting a recommended practice for how NREN publish their as-cones
by David Farmer 04 Apr '24

04 Apr '24

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 ===============================================

1 0

2025

2024

2023

2022

2021

Routing-wg