September 2024 - Test - lists.nanog.org

Re: Re: Survey on barriers for RPKI adoption
by Lancheng 10 Sep '24

10 Sep '24

Hi Sofia, I am currently an Assistant Researcher in Zhongguancun Lab, Beijing, China. Although I am not a network operator, I am very interested in this topic. Last year, I also did a survey asking network operators about the barriers to adopting ROA and ROV. That work has been accepted by NDSS 2024 [1]. I hope this paper could be helpful. [1] https://www.ndss-symposium.org/ndss-paper/understanding-route-origin-valida… Best, Lancheng >(Apologies for duplicates) >Hello everyone, >Following up on my message below, I wanted to let everyone know that we have extended the due date for the survey on barriers to RPKI adoption until Sep 19th. >If you are a network operator who manages IP space through multiple RIRs and you haven’t already participated in the survey, please take a moment to do so as we would really appreciate having your valuable input. It will only take a few minutes: >https://www.surveymonkey.com/r/CHLHLML >At this stage, we would like to particularly encourage those of you who have not created ROAs yet to understand what barriers or challenges you have experienced, as we don’t have enough representation from this group yet. >Thanks so much in advance for your input! >Warm regards, >Sofía >-- >I am sending this email at a time that suits me and the time zone I work in. Please feel free to read, and act on or respond, at a time that suits you.

2 1

ATT contact
by Doug Barrett 10 Sep '24

10 Sep '24

We’re seeing 30-50% packet loss on a hop around what we believe is Chicago area. Please reach out off-list if you can help.xxxx -> voiptest.sea.telecomsvc.com(64.282024-09-10T11:02:57-0500 Packets PingsHost Loss% Snt Last Avg Best Wrst StDev1. xxxxxxxx.xxxxxx.net(172.27.xxx.x) 0.0% 53 0.5 0.4 0.2 0.8 0.12. 10.1.xxx.xxx (10.1.xxx.xxx) 0.0% 53 2.6 4.5 1.7 29.1 4.23. 69.217.x.xx (69.217.x.xx) 0.0% 53 3.7 4.7 1.9 15.0 2.84. 12.91.81.197 (12.91.81.197) 0.0% 53 10.5 12.3 8.9 21.5 3.05. 12.122.162.186 (12.122.162.186) 0.0% 53 19.4 20.1 16.0 46.0 4.86. cgcil22crs.ip.att.net(12.122.1.129) 0.0% 53 25.7 20.5 13.3 38.9 4.57. 32.130.17.76 (32.130.17.76) 36.5% 52 14.6 16.9 12.6 34.4 5.48. 32.130.24.205 (32.130.24.205) 0.0% 52 24.0 18.9 14.6 35.1 4.89. 12.116.153.210 (12.116.153.210) 0.0% 52 17.3 31.8 15.5 133.0 26.310. 141.101.73.202 (141.101.73.202) 0.0% 52 26.0 30.8 14.0 131.5 25.011. 172.70.125.88 (172.70.125.88) 0.0% 52 16.1 17.4 13.2 23.9 2.4 172.70.125.46 (172.70.125.46) 172.70.125.213 (172.70.125.213) 172.70.125.165 (172.70.125.165) 172.70.125.214 (172.70.125.214) 172.70.125.87 (172.70.125.87) 172.70.125.207 (172.70.125.207) 172.70.125.199 (172.70.125.199) 172.70.125.161 (172.70.125.161)12. 172.70.125.157 (172.70.125.157) 0.0% 52 17.7 18.8 13.7 36.3 4.7 172.70.125.206 (172.70.125.206) 172.70.125.170 (172.70.125.170) 172.70.125.181 (172.70.125.181) 172.70.125.18 (172.70.125.18) 172.70.125.98 (172.70.125.98) 172.70.125.120 (172.70.125.120) 172.70.125.176 (172.70.125.176) 172.70.125.161 (172.70.125.161)13. 172.70.125.89 (172.70.125.89) 0.0% 52 28.6 19.3 13.8 36.1 5.6 172.70.125.199 (172.70.125.199) 172.70.125.115 (172.70.125.115) 172.70.125.19 (172.70.125.19) 172.70.125.25 (172.70.125.25) 172.70.125.108 (172.70.125.108) 172.70.125.102 (172.70.125.102) 172.70.125.137 (172.70.125.137) 172.70.125.165 (172.70.125.165)14. (waiting for reply)15. 64.28.116.197 (64.28.116.197) 0.0% 52 61.1 65.0 59.2 95.6 7.4 64.28.116.195 (64.28.116.195)16. voiptest.sea.telecomsvc.com(64.28.122. 0.0% 52 61.0 65.2 59.3 85.8 6.7

3 2

MS Network issue ?
by Scott Q. 09 Sep '24

09 Sep '24

Anyone else noticing issues accessing MS's network from Canada ? Started about 1h30 ago, huge latency/packet loss 2. AS??? mtl-bvh-dis-1 (216.187.113.108) 0.0% 100 0.7 1.7 0.3 33.6 4.9 3. AS??? ae3.tor-fr709-cor-1.peer1.net (216.187.88.88) 0.0% 100 7.1 7.4 6.9 26.1 2.1 4. AS??? microsoft.ip4.torontointernetxchange.net (206.108.34.160) 0.0% 100 16.4 16.8 16.3 22.0 1.0 5. AS8075 ae22-0.icr01.yto20.ntwk.msn.net (104.44.237.151) 0.0% 100 18.4 18.5 16.2 49.5 4.9 6. AS8075 be-120-0.ibr02.yto20.ntwk.msn.net (104.44.20.165) 42.0% 100 227.6 228.1 227.5 246.7 2.5 7. AS8075 be-7-0.ibr02.cle02.ntwk.msn.net (104.44.29.105) 22.0% 100 227.9 228.3 227.8 246.3 2.1 8. AS8075 be-3-0.ibr02.ch2.ntwk.msn.net (104.44.29.253) 0.0% 100 236.6 238.5 236.2 329.0 12.9 9. AS8075 be-6-0.ibr02.dsm05.ntwk.msn.net (104.44.18.217) 72.0% 100 427.9 437.3 424.1 537.0 27.7 10. AS8075 be-8-0.ibr02.cys04.ntwk.msn.net (104.44.18.150) 64.0% 100 429.2 430.4 419.8 498.8 12.7 11. AS8075 be-7-0.ibr02.mwh01.ntwk.msn.net (104.44.18.225) 0.0% 100 236.4 239.6 236.0 323.4 12.9 12. AS8075 be-2-0.ibr03.mwh01.ntwk.msn.net (104.44.16.80) 82.0% 100 542.4 437.7 424.5 542.4 28.6 13. AS8075 be-6-0.ibr01.pdx30.ntwk.msn.net (104.44.30.74) 0.0% 100 235.0 248.7 234.9 388.4 31.3 14. AS8075 be-7-0.ibr01.tyo79.ntwk.msn.net (104.44.18.166) 0.0% 100 227.9 238.0 227.8 350.5 26.6 15. AS8075 be-9-0.ibr01.sg2.ntwk.msn.net (104.44.18.213) 88.0% 100 423.4 428.4 422.5 467.7 12.5 16. AS8075 ae100-0.icr01.sg2.ntwk.msn.net (104.44.11.188) 74.0% 100 429.2 427.0 419.4 443.1 5.3

1 0

CenturyLink Denver - failing hardware
by Elliott Sims 09 Sep '24

09 Sep '24

I'm attempting to get ahold of someone at CenturyLink/Quantum/Lumen about an unusual hardware failure that's causing issues for a lot of customers in southwest Denver. It appears that a buffer in one link in a LAG or ECMP group is flipping a bit around 10MB in to a zero. They have a bunch of tech visits scheduled to various people, and I assume after enough of those fail to fix the issue it'll eventually filter up to the NOC or neteng in a couple of weeks, but I'm hoping to short-circuit that a bit. Symptoms/troubleshooting: No change on home router replacement No difference across devices ICMP ping works fine, even padded to 1460 with 00 or FF SSH/SCP work (generally limited to 2MB or 4MB buffers/window depending on the version) HTTPS fails frequently Downloading a 10MB 0-filled file via HTTP succeeds consistently. Downloading a 10MB 1-filled file fails frequently Specifically, any 1-filled file with 10482846 or more bytes sees frequent failures For a consistent 5-tuple and large 1-filled file, failures are consistent.

1 0

Survey on barriers for RPKI adoption
by Sofia Silva Berenguer 08 Sep '24

08 Sep '24

(Apologies for duplicates) Hello everyone, As part of the NRO RPKI Program<https://www.nro.net/technical-coordination/security/certification/#rpki_pro…> we would like to know more about the community’s expectations with regard to consistency in RPKI implementations across the Regional Internet Registries (RIRs). Our end goal is to define what a single, global RPKI system would look like. We want to know more about the experience of managing resources through multiple RIRs in order to understand whether the differences in the RIRs' RPKI implementations are hindering RPKI adoption, more specifically Route Origin Authorization (ROA) creation, and if so, which differences are the most painful. This will allow us to focus on making those aspects of the RPKI system more consistent. Are you a network operator with permissions to create ROAs for IP space allocated by multiple RIRs? If so, we would greatly appreciate your participation in our survey before September 12: https://www.surveymonkey.com/r/CHLHLML We want to hear from those who have already created ROAs as well as those who may be considering creating ROAs but have not yet done so. If this is not you, please consider forwarding this email to anyone else you know who could participate in the survey. Note that survey participants can enter a drawing for the equivalent to USD 35 e-gift voucher (If e-gift vouchers cannot be used in the winner's economy, an alternative gift will be provided). We really appreciate your participation! Warm regards, Sofía -- I am sending this email at a time that suits me and the time zone I work in. Please feel free to read, and act on or respond, at a time that suits you. ____________________________________________________________________ Sofía Silva Berenguer RPKI Program Manager, NRO / Process and Productivity Engineer, APNIC e: sofia(a)apnic.net<mailto:sofia@apnic.net> ____________________________________________________________________

1 1

Spoofer Report for NANOG for Aug 2024
by CAIDA Spoofer Project 08 Sep '24

08 Sep '24

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Aug 2024: ASN Name Fixed-By 55 UPENN 2024-08-06 394195 CLEARNETWORX 2024-08-12 25853 ELJY30540 2024-08-29 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Aug 2024: ASN Name First-Spoofed Last-Spoofed 40676 AS40676 2016-08-29 2024-08-31 27364 ACS-INTERNET 2016-09-27 2024-08-29 1403 EBOX 2016-11-12 2024-08-27 2152 CSUNET-NW 2017-11-08 2024-08-28 33363 BHN-33363 2018-11-29 2024-08-30 21804 ACCESS-SK 2019-06-09 2024-08-25 36352 AS-COLOCROSSING 2020-10-08 2024-08-23 4922 SHENTEL 2021-12-28 2024-08-22 12183 TALKIE-COMMUNICATIONS 2022-12-10 2024-08-31 3701 NERONET 2023-04-18 2024-08-31 400282 2023-04-27 2024-08-30 393577 SCCNET 2023-05-03 2024-08-31 202400 2023-05-08 2024-08-26 61461 Airtek Solutions C.A. 2023-05-13 2024-08-16 394684 WISPERNET 2024-01-17 2024-08-30 214961 2024-05-14 2024-08-30 393530 TLU 2024-05-22 2024-08-28 19935 CRRS 2024-05-29 2024-08-24 398182 BLN 2024-06-17 2024-08-15 216211 2024-06-22 2024-08-23 13371 DUKE-INTERCHANGE 2024-07-03 2024-08-14 57308 Rossvyazinform 2024-08-10 2024-08-24 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Seeking IANA ccTLD contact
by Chad Dailey 08 Sep '24

08 Sep '24

At some point during or after Neustar .us bits were assigned to GoDaddy, we lost administrative control over some $govtdayjob namespace, and it is claimed to now be held by the registry. Fast forward, we have a need to get things properly aligned. Have been trying to get things sorted out in good faith but the process is dragging on, and we are getting the side-eye from leadership because we're not getting a related issue resolved. I have a case number and supporting documentation, for what it's worth. Next step is legal, and I'd really like to avoid that mess. If you're an authoritative person that can help get this sorted, or have contact information for that person or persons, please reach out to me. Thank you, Chad D

3 5

Hurricane Electric now supports ASPA for route filtering
by Mike Leber 07 Sep '24

07 Sep '24

Hurricane Electric now uses ASPA to do hop by hop checking of AS paths when deciding which routes to accept when building prefix filters. Here is an example of a route failing the ASPA check. 44.31.69.0/24,rejected,AS path 4635 9002 945 7480 38254 38254 38254 38254 38254 ASPA record exists for 7480 and 945 is not listed as a provider. 44.31.73.0/24,rejected,AS path 4635 9002 945 7480 ASPA record exists for 7480 and 945 is not listed as a provider. These were found on the HKIX route servers (this example may be gone by the time you look at it, or it may exist for a while): https://routing.he.net/index.php?cmd=display_filter&as=4635&af=4&which=reas… For Hurricane Electric, the ASPA filtering is part of the prefix filter generation used for all customers and peers, which is responsible for the decision to accept a prefix. The vast majority of the route filtering decisions occur at this stage. We will shortly be adding ASPA reactive filtering which will monitor for prefixes that we have accepted that later become invalid. (Possible gross oversimplification ahead.) ASPA (Autonomous System Provider Authorization) is a relatively easy to understand add-on to RPKI that allow an ASN to create a record that lists which ASNs can be providers for that ASN. The concepts are "customer" (an ASN) and "providers" (a list of ASNs). How did we do this? How can you do something similar? You should already be familiar with RPKI and should set up an RPKI validator, ideally one with ASPA support. Test to see that you can validate origin and prefix pairs so that you know you have the RPKI validator working. Then do research regarding your specific RPKI validator to dump all the ASPA objects currently being published. The following article is an interesting starting point for the concepts involved and to help you play around: https://as51019.com/posts/aspa-bird2/ In the blog post the experimenter was building AS path filters for bird using ASPA records from a dump from routinator. If you wanted a routing daemon with builtin early stage ASPA support, I'm told you can use openbgpd with rpki-client. I'm sure Job will be able to give much better or more accurate guidance regarding ASPA software, protocols, and terminology.

1 0

Hurricane Electric now supports "Never via route servers" (the peeringdb flag)
by Mike Leber 07 Sep '24

07 Sep '24

Hurricane Electric now supports "Never via route servers" (the peeringdb flag) as part of our route filtering algorithm. Using peeringdb, an ASN may indicate that its routes should never be learned via route servers. As a simple detection method, currently route servers are detected at run time when the first AS hop of a path does not match the peer AS. When checking a path learned from a route server each hop is checked to see if it has "Never via route servers" set to true. Here is an example of a route failing the "Never via route servers" check. 80.96.25.0/24,rejected,received AS path 9009 62350 from a route server and 62350 has indicated that it is never to be learned via route servers (peeringdb flag). This path was learned via the Balcan-IX route servers (this example may be gone by the time you look at it, or it may exist for a while): https://routing.he.net/index.php?cmd=display_filter&as=24745&af=4&which=rea… The "Never via route servers" filtering is part of the static prefix filter generation, which is responsible for the decision to accept a prefix.

1 0

Apple Geolocation contact?
by J.R. Raith 06 Sep '24

06 Sep '24

Hi All, I have a laboratory in my department which thinks it's in central Russia when using Apple Maps on macOS and iOS devices. (I've also seen it in Google Maps on macOS, which I assume is GMaps getting its location from the OS). The lab has also reported Bhutan, Malta, and the equally exotic Ohio. This room is a shielded from GPS and cellular signals, but may pick up neighboring Access Points. Step outside of that specific room and you're back in Colorado. Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings. I've tried swapping out the Access Point in the lab. I've tried dropping a pin in Apple Maps and reporting the location as incorrect, repeatedly and with separate devices. I started looking at geolocatemuch, but I'm not sure that's the problem in this instance. The NAT IP we come from shows proper location in infosniper. I'd love to chat with an Apple person about how to solve it. Wish I could get frequent flyer miles for this... Thanks, J.R. Raith _________________________________________________ Network Administration & Desktop Support JILA Computing - University of Colorado, Boulder

4 5