August 2023 - Test - lists.nanog.org

IANA AS Numbers Registry Update
by David Dong 10 Aug '23

10 Aug '23

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to the RIPE NCC: 213404-214427 Assigned by RIPE NCC 2023-08-10 214428-215451 Assigned by RIPE NCC 2023-08-10 215452-216475 Assigned by RIPE NCC 2023-08-10 You can find the registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en Best regards, David Dong IANA Services Sr. Specialist

1 0

ARIN Consultation on Automatic Creation of IRR Route Objects
by John Curran 10 Aug '23

10 Aug '23

NANOGers - As I noted earlier, we have opened a community consultation seeking input on the desired technical functionality for RPKI ROA / IRR route object integration in the ARIN registry - see the message attached below for details. If you have particular views on this topic, then please subscribe to the arin-consult mailing list (open to all at http://lists.arin.net/mailman/listinfo/arin-consult) and provide your input. Thanks! /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net> Subject: [arin-announce] Consultation on Pending Functionality for Automatic Creation of IRR Route Objects for Uncovered ROAs Date: August 10, 2023 at 3:35:01 PM EDT To: "arin-announce(a)arin.net" <arin-announce(a)arin.net> Dear ARIN Community, ARIN is seeking feedback from the community regarding a specific aspect of the recent ARIN Online functionality that was deployed on 7 August 2023. This upgrade to ARIN Online brought several new features – including tighter integration of ARIN’s Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) routing security services. Upon further review and out of an abundance of caution, we have decided to pause the additional functionality that creates corresponding IRR Route Objects for every Route Origin Authorization (ROA) created. We have also paused the functionality that automatically creates IRR Route Objects for all preexisting ROAs that presently lack a matching Route Object. We recognize the importance of ensuring that our services align with the needs and expectations of our community and believe that additional time for community consultation on this integration functionality is warranted. The current development plan is to provide an opt-in feature to allow for the creation of IRR Route Objects during new ROA creation in the near future. We are seeking operator input through this community consultation (https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/) to gather input on the desirability of additional functionality related to integrating RPKI and IRR security services. The questions for community consideration are: - Should the automatic creation of IRR route objects for resources that have RPKI ROAs be compulsory, the default setting, or require explicit opt-in? - Should IRR Objects be managed via a direct linkage to a ROAs such that they can only be deleted through deletion of the covering ROA, or should ARIN continue to support independent management of IRR route objects? - Should ARIN automatically create managed IRR Route Objects for all validated ROAs in the Hosted RPKI repository that do not have matching IRR Route Objects today? - If so, what is the anticipated benefit of doing so? Conversely, if this functionality is not desired, why not? - If a customer agrees to link a ROA with the IRR, what is the appropriate number of route objects that should be created based on the ROA prefix and max length configuration? Would a “least specific” route object meet expectations? We sincerely apologize for any inconvenience that pausing this functionality may have caused and appreciate your understanding as we work to ensure that our services are aligned with the interests of the community. I encourage all community members to provide their comments and feedback on this matter – the feedback you provide during this consultation will be instrumental in determining how ARIN moves forward with this RPKI/IRR integration functionality. Please provide comments to arin-consult(a)arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open until 5:00 PM ET on 10 September 2023. ARIN seeks clear direction through community input, so your feedback is important. Thank you for your continued support and engagement. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net) Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

1 0

Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)
by John Curran 10 Aug '23

10 Aug '23

NANOGers - We have made some fairly significant changes for those customers using ARIN Online for routing security administration – see attached message for specifics. FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net> Subject: [arin-announce] New Features Added to ARIN Online Date: August 7, 2023 at 1:37:51 PM EDT To: <arin-announce(a)arin.net> ARIN is pleased to present the latest version of ARIN Online, including improvements, new features, and updates. Full release notes are included at the end of this message. All ARIN systems have been restored and are now operating normally. We thank you for your patience. If you have additional questions, comments, or issues, please submit an Ask ARIN ticket using your ARIN Online account or contact the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660. Regards, Mark Kosters Chief Technology Officer American Registry for Internet Numbers (ARIN) Release Notes - Navigation and eligibility status for ARIN’s routing security services, the Resource Public Key Infrastructure (RPKI), and Internet Routing Registry (IRR) have been condensed into a single Routing Security Dashboard in ARIN Online. We have also made the navigation of the IRR pages consistent with the RPKI portions of the website. - Abuse, Network Operation Center (NOC), and DNS Points of Contact now have read-only viewing privileges for RPKI details in both ARIN Online and the RESTful API. - Creating a new Route Origin Authorization (ROA) in ARIN Online now automatically creates and manages the matching IRR Route Objects based on the ROA prefix and max length configuration. If the creation of a ROA would result in more than 256 IRR Route Objects, no managed IRR Route Objects will be created. Managed IRR Route Objects may not be removed independently of their covering ROAs. Deleting a ROA in ARIN Online will automatically delete its corresponding managed IRR Route Objects. In the coming weeks, ARIN will create managed IRR Route Objects for all preexisting ROAs that do not currently have matching IRR Route Objects. Preexisting IRR Route Objects that match ROAs will be associated with the covering ROA. - To create feature parity with templates, we have added the capability to modify reassignment information within ARIN Online without any changes to the registration date. - Customers can begin the application process for the Qualified Facilitator Program in ARIN Online. ARIN Qualified Facilitators serve as resources for the community by assisting organizations seeking to acquire or transfer IPv4 or Autonomous System Number (ASN) resources. _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net) Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

4 7

Is there anyone from Bell Mobility to help us unblock a routing issue?
by Raphael Grenier 10 Aug '23

10 Aug '23

Hi, We are looking for someone from Bell mobility NOC. We are a VoIP service provider: Cloudli Communication ASN#18637. We are peering with Bell ISP and advertising the IP block 198.38.7.0/24. We have connectivity problems with our customers, when they are on the Bell LTE networks in the Lac Saint-Jean region. For information, when customers move to another region, everything works fine. This disorder started in April. Thank you Raphael Grenier

1 0

Last Mile ISP Quality Measurements
by Mike Hammett 09 Aug '23

09 Aug '23

What are other last mile ISPs doing to measure the quality of their connections? We all know pinging various destinations. We also all know that pinging a destination doesn't necessarily tell you the whole quality story. I currently have Smokeping pulling the HTTPS for about 20 - 25 of the "top" websites, per the old Alexa rankings. I feel as though I could be doing more. I am more closely wanting to emulate the end-user experience in a repeatable, quantifiable fashion. I'd like to do A/B comparisons as well. When I make X change, how does it change? If I'm already doing the low-hanging fruit path, then so be it. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

6 7

VIDEO - NANOG Talks to Seattle Community Network + Guest Column: Geoff Huston
by Nanog News 09 Aug '23

09 Aug '23

*VIDEO - NANOG Talks to Seattle Community Network* *NANOG Talks to SCN About Connecting the Underserved Across Puget Sound* *The Seattle Community Network (SCN) is an Internet built by the community for the community.* NANOG Executive Director Edward McNair sat down with a volunteer of SCN + Ph.D. candidate in the Department of Computer Science at the University of Washington, Esther Jang, at our most recent meeting, NANOG 88 (Seattle, Wa, 12 - 14 Jun) to discuss the mission of SCN and how they are connecting + empowering underserved regions locally. *WATCH NOW * <https://www.google.com/url?q=https://nanog.us20.list-manage.com/track/click…> *Guest Column: Geoff Huston "The Source of Time, According to a Technologist"* *Exploring the Definition of Time from Early Astronomical Observations to its use in the Internet Today* An underappreciated aspect of our digital infrastructure is how dependent we are on time. Disrupting time leads to communication disruption and can result in various forms of service compromise. A synchronized view of the time is essential to the Internet's service platform. *READ MORE * <https://www.google.com/url?q=https://nanog.us20.list-manage.com/track/click…> *Upcoming Fall Online Course* *Fundamentals of Designing and Deploying Computer Networks* *Date: *11 September – 20 October 2023 *Title:* Fundamentals of Designing and Deploying Computer Networks *Description:* This course will discuss the fundamentals of networking, Ethernet, and WIFI technologies. It will additionally teach the planning, design, and deployment of simple LANs and cover how to connect a LAN to the Internet. The course will also present the most common ways to connect a LAN to the Internet (Mobile Internet, ADSL, Fiber) and how to set up the connections. *MORE INFO * <https://www.internetsociety.org/learning/ddcn/> *Video of the Week* *Deploying a Backbone in APAC with Pierre-Yves Maunier* Maunier discusses what his team learned and changed during their multi-year journey expanding their network footprint in the Asia Pacific region. He will speak about the challenges they faced, their mistakes, and how they worked around them with various iterations of their deployment. *WATCH NOW * <https://www.youtube.com/watch?v=TS9xsOPCVHI&t=217s>

1 0

Looking for a Telus cellular last mile facilities operations contact
by Eric Kuhnke 09 Aug '23

09 Aug '23

I have observed a Telus cellular site shelter that's making a terrible, not normal ventilation noise. It's a 12+ foot length prefab assemble on site shelter located in the basement parking garage of a 23 floor tower in downtown Vancouver. I know what this POP's normal ventilation sounds like, having seen.and heard it in operation for several years now, and this isn't healthy. Based on the amount of sectors on the roof and ptp microwave links from this site I would guess this is a more important than ordinary site, so if Telus doesn't want to wait for it to overheat and die, contact me off list for the street address of the building. I have already tried spending about 45 minutes on the phone with Telus customer service (I am not a customer) and this has been making the "I am a dying ventilation blower" noise for two weeks now.

1 0

Spoofer Report for NANOG for Jul 2023
by CAIDA Spoofer Project 08 Aug '23

08 Aug '23

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 Jul 2023: ASN Name Fixed-By 54825 PACKET 2023-07-02 6128 CABLE-NET-1 2023-07-03 6124 MARIST 2023-07-06 14576 HOSTING-SOLUTIONS 2023-07-16 394233 CLOUDWIFI 2023-07-21 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jul 2023: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL3 2016-03-06 2023-07-14 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2023-07-27 20412 CLARITY-TELECOM 2016-09-30 2023-07-31 25787 ROWE-NETWORKS 2016-10-21 2023-07-28 11427 TWC-11427-TEXAS 2016-10-21 2023-07-25 10796 TWC-10796-MIDWEST 2016-10-24 2023-07-30 271 BCNET 2016-10-24 2023-07-29 852 ASN852 2017-04-16 2023-07-31 53274 3DB-WIRELESS 2019-01-18 2023-07-05 46997 2021-12-22 2023-07-27 394414 E2WS 2022-05-08 2023-07-26 397086 GLOBAL-FRAG-NETWORKS-HOUSTON 2022-06-16 2023-07-25 400517 2022-10-03 2023-07-10 12183 TALKIE-COMMUNICATIONS 2022-12-10 2023-07-21 964 GONET-ASN-17 2023-03-15 2023-07-07 41378 KirinoNET 2023-03-23 2023-07-28 3701 NERONET 2023-04-18 2023-07-26 400282 2023-04-27 2023-07-28 13693 NTS-ONLINE 2023-05-05 2023-07-29 46690 SNET-FCC 2023-05-20 2023-07-29 200063 CAMINI-IMPEX 2023-06-16 2023-07-21 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

Fwd: NTP Sync Issue Across Tata (Europe)
by Mel Beckman 06 Aug '23

06 Aug '23

Or one can read recent research papers that thoroughly document the incredible fragility of the existing NTP hierarchy and soberly consider their recommendations for remediation: https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper… Or simply use non-Internet NTP servers based on a Stratum-0 GPS source for mission-critical network timing. Until then, we may all wake up one morning and discover massive data breaches traced to an unfounded reliance on insecure public NTP servers. Then the game truly will be over, but not in our favor. -mel On Aug 6, 2023, at 2:35 PM, Rubens Kuhl <rubensk(a)gmail.com> wrote: Or one can select NTS-capable NTP servers, like those 5: a.st1.ntp.br b.st1.ntp.br c.st1.ntp.br d.st1.ntp.br gps.ntp.br Or any other NTP server that has NTS deployed. Game-over for NTP impersonation. Rubens On Sun, Aug 6, 2023 at 4:41 PM Mel Beckman <mel(a)beckman.org> wrote: In a nutshell, no. Refer to my prior cites for detailed explanations. For a list of real-world attack incidents, see https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse# -mel On Aug 6, 2023, at 12:03 PM, Royce Williams <royce(a)techsolvency.com> wrote: Naively, instead of abstaining ;) ... isn't robust diversity of NTP peering a reasonable mitigation for this, as designed? Royce On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman <mel(a)beckman.org> wrote: William, Due to flaws in the NTP protocol, a simple UDP filter is not enough. These flaws make it trivial to spoof NTP packets, and many firewalls have no specific protection against this. in one attack the malefactor simply fires a continuous stream of NTP packets with invalid time at your firewall. When your NTP client queries the spoofed server, the malicious packet is the one you likely receive. That’s just one attack vector. There are several others, and all have complex remediation. Why should people bother being exposed to the risk at all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve already described. Having suffered through such attacks more than once, I can say from personal experience that you don’t want to risk it.

1 0

Re: NTP Sync Issue Across Tata (Europe)
by Rubens Kuhl 06 Aug '23

06 Aug '23

The paper suggests the compromise of critical infrastructure. So, besides not using NTP, why not stop using DNS ? Just populate a hosts file with all you need. BTW, the stratum-0 source you suggested is known to have been manipulated in the past (https://www.gps.gov/systems/gps/modernization/sa/) so you need to bet on that specific state actor not returning to old habits. OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you can keep using GPS as well. If GPS goes bananas on timing, that source will just be disregarded (one of the features of the NTP architecture that has been pointed out over and over in this thread and you keep ignoring it). Rubens Rubens On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman <mel(a)beckman.org> wrote: > Or one can read recent research papers that thoroughly document the > incredible fragility of the existing NTP hierarchy and soberly consider > their recommendations for remediation: > > [image: preview.png] > > ndss2021_1A-2_24302_paper > <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper…> > PDF Document · 1.7 MB > <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper…> > > <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper…> > > Or simply use non-Internet NTP servers based on a Stratum-0 GPS source for > mission-critical network timing. > > Until then, we may all wake up one morning and discover massive data > breaches traced to an unfounded reliance on insecure public NTP servers. > Then the game truly will be over, but not in our favor. > > -mel > > On Aug 6, 2023, at 2:35 PM, Rubens Kuhl <rubensk(a)gmail.com> wrote: > > Or one can select NTS-capable NTP servers, like those 5: > a.st1.ntp.br > b.st1.ntp.br > c.st1.ntp.br > d.st1.ntp.br > gps.ntp.br > > Or any other NTP server that has NTS deployed. Game-over for NTP > impersonation. > > > Rubens > > On Sun, Aug 6, 2023 at 4:41 PM Mel Beckman <mel(a)beckman.org> wrote: > > > In a nutshell, no. Refer to my prior cites for detailed explanations. For > a list of real-world attack incidents, see > > > https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse# > > > > -mel > > > On Aug 6, 2023, at 12:03 PM, Royce Williams <royce(a)techsolvency.com> > wrote: > > > > > Naively, instead of abstaining ;) ... isn't robust diversity of NTP > peering a reasonable mitigation for this, as designed? > > > Royce > > > On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman <mel(a)beckman.org> wrote: > > > William, > > > Due to flaws in the NTP protocol, a simple UDP filter is not enough. These > flaws make it trivial to spoof NTP packets, and many firewalls have no > specific protection against this. in one attack the malefactor simply fires > a continuous stream of NTP packets with invalid time at your firewall. When > your NTP client queries the spoofed server, the malicious packet is the one > you likely receive. > > > That’s just one attack vector. There are several others, and all have > complex remediation. Why should people bother being exposed to the risk at > all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve > already described. Having suffered through such attacks more than once, I > can say from personal experience that you don’t want to risk it. > > >

1 0