- NANOG - lists.nanog.org

Looking for Peering Contact at AS16509
by W. Bontekoe 17 Jan '25

17 Jan '25

Hi, I'm trying to connect with someone responsible for managing peering relations in EU for AS16509 (Amazon). Unfortunately, several attempts to reach them via the address on peeringdb (peering-emea(a)amazon.com) have been unanswered. Greatly appreciate if an appropriate contact could kindly reach out to me off-list. -- W. Bontekoe Principal Site Reliability Engineer

1 0

RPKI's 2024 Year in Review
by Job Snijders 17 Jan '25

17 Jan '25

Dear all, Happy new year everyone! Having just closed the book on another orbit around the sun - let's look back at how RPKI did in 2024! In this memo I'll share some RPKI statistics, summarize highlights from the IETF Standards Development process, and reflect on emerging trends. Year to Year Growth of the distributed RPKI database =============================================================== A straightforward method to compare 2023 and 2024 is to look at the absolute numbers. The below table was constructed by comparing two December 31st RPKIviews.org snapshots [1] based on the the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors. 2023-12-31 2024-12-31 Total cache size (KiB): 1,546,728 2,021,784 (+31%) Total number of files (objects): 309,802 415,384 (+34%) Wall time validation run (seconds): 163 228 (+40%) Publication servers (FQDNs): 63 53 (-16%) Certification authorities: 40,511 44,935 (+11%) Route origin authorizations: 188,345 280,692 (+49%) Uniq VRPs: 497,341 639,909 (+29%) Average ROAIPAddresses per ROA: 2.7 2.3 (-15%) IPv4 addresses covered: 2,502,293,068 2,726,513,768 (+ 9%) Uniq IPv4 addresses covered: 1,502,281,680 1,658,281,248 (+10%) IPv6 addresses covered: 17,263 * 10^30 17,392 * 10^30 (+ 1%) Uniq IPv6 addresses covered: 15,128 * 10^30 15,139 * 10^30 (+ 0%) Uniq origin ASNs in ROAs: 40,656 47,282 (+16%) Uniq ASPA Customer ASIDs: 56 87 (+55%) The number of IPv4 addresses covered by ROAs saw similar growth compared to 2023. It's not entirely clear to me what's going on with IPv6, but on the IPv6 side of the house growth seems to be stalling. The NIST RPKI Deployment Monitor seems to corroborate these observations: https://rpki-monitor.antd.nist.gov/ROV/20250103.00/All/All/6#div2 As predicted in last year's review, nowadays more than half of both the IPv4 and IPv6 routes in the global routing system are covered by RPKI ROAs (~ 54%). Kentik estimates that around 74% of IP traffic is destined towards ROA covered destinations. These numbers mean it will be worth your while to create and use ROAs for BGP Origin Validation. This year's report includes new metrics: "Uniq ASPA Customer ASIDs", this field provides a simple indicator for global ASPA deployment on the signer side. At the moment about 0.001% of Autonomous Systems in the Internet global routing system published an ASPA record, so it's still very early days for ASPA! Another new metric is "Wall time validation run (seconds)". To produce this metric the two snapshots are processed through the same (modern) RPKI cache implementation on the same hardware omitting any network operations. This metric suggests that as the RPKI grows in size and/or number of files, processing time also increases. Please note that the wall time metric is not comparable between successive annual reports (for example, next year I might have a different laptop, or use a different validator implementation) - but within a single annual report the metric comparison is apples to apples. To reproduce: $ rpki-client -V rpki-client 9.3 $ time rpki-client -P 1704066710 -n -d rpki-20231231T235150Z/data /tmp/ $ time rpki-client -P 1735689171 -n -d rpki-20241231T235251Z/data /tmp/ Onwards to the next metric, "Average ROAIPAddresses per ROA" this shows how many IP prefixes, on average, are contained within a single ROA object. The higher the number of ROAIPAddresses per ROA, the higher computational efficiency is. "Efficiency" in this context arises from validators spending the computational cost of validating a single EE certificate and yielding more than 1 ROAIPAddress. Under the RIPE NCC TAL one yields 6.5 prefixes per ROA, while in the ARIN region this is number is 1.1 prefixes per ROA. As stewards of this technology, we need to keep an eye on the overall efficiency of the RPKI to ensure things don't get out of hand. SIDROPS - Working Group developments =============================================================== Some quick updates from the IETF working group responsible for development and maintenance of the RPKI technology stack! ASPA - where we at? ------------------- While most of the ASPA specification documents are steadily moving towards completion, the RPKI-To-Router (RTR) specification unfortunately appears to be progressing with great difficulty. With so many people excited about the prospect of using ASPA to prevent route leaks, it's sad to see a select few individuals dragging their feet to dot the i's and cross the t's. As things stand, some parts of the draft RTR specification are unimplementable and other parts appear underspecified. Perhaps appointment of an extra document editor would help? In last year's report I was more optimistic about the delivery timeline than I am this year. I now expect publication of the ASPA specs as RFCs not to happen earlier than 2026. For an overview of open action items, see: https://mailarchive.ietf.org/arch/msg/sidrops/fwPjecfnlU5JYi_hU-Sh3o7WRHQ/ Finished work ------------- The good news is that 2024 turned out to be a productive year in terms of tidying up various aspects of the RPKI technology stack. "Tidying up" in this context means resolving potentially detrimental system behavior for some edge cases, resolving underspecification in older documents, and documenting optimizations. A quick overview of RFC publications in the last 12 months: * RFC 9582 - A Profile for Route Origin Authorizations (ROAs) https://www.rfc-editor.org/rfc/rfc9582.html The new ROA specification clarifies the requirements for IP address and AS identifier X.509 certificate extensions, its ASN.1 notation was revised with additional backwards compatible constraints, errata were incorporated, and a canonicalization procedure was specified for the content of ipAddrBlocks. * RFC 9589 - On the Use of the CMS Signing-Time Attribute in RPKI Signed Objects https://www.rfc-editor.org/rfc/rfc9589.html 9589 describes mechanism for a 'cross-layer optimization' which enables Relying Parties (RPs) - when switching from RRDP to RSYNC - to save on bandwidth consumption. All five RIRs and rpki-client support this mechanism. See the following deep-dive for more information: https://blog.apnic.net/2023/12/04/using-timestamps-inside-rpki-objects-to-o… * RFC 9674 - Same-Origin Policy for the RRDP https://www.rfc-editor.org/rfc/rfc9674.html A potential security issue was discovered in RRDP: from one RRDP server references could be made to resources hosted on another RRDP server, causing RPs to follow the reference and waste bandwidth. The solution turned out to be simple: RPs should not follow references to resources hosted on other origins. All actively-maintained RPs implementations adopted this approach. * RFC 9697 - Detecting RRDP Session Desynchronization https://www.rfc-editor.org/rfc/rfc9697.html For RRDP to work well, once Delta files are published, Deltas are not expected to change over time. Delta files are immutable. A mechanism was devised for RPs to detect occurrences of unexpected file mutations and how to recover. Most actively-maintained RP implementations adopted this approach. Final words =============================================================== RPKI has become the #1 tool in the toolbox to prevent routing incidents. Implementing RPKI allows operators to improve network reliability by strengthening the security and integrity of the global Internet routing system. I'm excited to see what the coming year will bring! Kinds regards, Job Snijders Data sources: RPKI Views - http://rpkiviews.org/ https://dango.attn.jp/rpkidata/2023/12/31/rpki-20231231T235150Z.tgz https://dango.attn.jp/rpkidata/2024/12/31/rpki-20241231T235251Z.tgz

1 0

Edgio Bankruptcy - Services cut-off
by Pacheco, Matheus 17 Jan '25

17 Jan '25

Hi Nanog Anybody here still using services with Edgio that have some details (or any sort of information) regarding the services cut-off that was suppose to happen today ? I heard from a former Edgio partner that the cut-off was postponed to tomorrow, but not much info than that. Ive tried to contact Akamai to get and they are unresponsive. Cheers, -- Matheus Pacheco Triton Digital | Montreal

5 4

US executive order forces all US goverment resoruces to be with ARIN/etc?
by Ben Cartwright-Cox 17 Jan '25

17 Jan '25

Still reading this very word dense executive order that came out recently: https://www.whitehouse.gov/briefing-room/presidential-actions/2025/01/16/ex… I did notice however that it has: > (i) Within 90 days of the date of this order, FCEB agencies shall take steps to ensure that all of their assigned Internet number resources (Internet Protocol (IP) address blocks and Autonomous System Numbers) are covered by a Registration Services Agreement with the American Registry for Internet Numbers or another appropriate regional Internet registry. I don't have numbers on hand for how much US Gov space is already with ARIN, but this seems like a pretty nice win for ARIN getting an order for the US Gov legacy space attached to them (mentioned by name), while other RIRs are available in that order, I don't imagine it's going to other RIRs :)

6 9

Re: Seeking AS36351 Softlayer Contact
by Aaron Atac 16 Jan '25

16 Jan '25

Thanks, all. Jan 16, 2025 at 2:56 PM by nanog(a)nanog.org: > Seeking AS36351 Softlayer contact > > -Aaron >

1 0

AT&t ABF NYC
by Robert DeVita 16 Jan '25

16 Jan '25

FYI. AT&T is discontinuing their ABF service in New York. What's Happening with Existing ABF Customers in NY AT&T Business Fiber customers in New York will be able to keep their current ABF service until March 1 at no charge, as they find other options for broadband service. Customers must do one of the following before 3/1/25, when their ABF services will be disconnected: * Sign a 12-month contract for existing ABF services at current rates * Switch to AT&T Dedicated Internet (ADI) or AWB with standard pricing * Take no action, and their ABF services will be disconnected on 3/1/25 Existing customers are being contacted via email and direct mail to inform them of the changes and offer the option to either sign a 12-month contract or migrate to AWB or ADI. AT&T’s nationwide wireless service will not change in New York. AIA-B and ABF are still offered in all other qualified locations and states. We value our customers and AT&T will continue to support policies that promote capital investment, innovation and a competitive market. Get Outlook for iOS<https://aka.ms/o0ukef>

9 13

Seeking AS36351 Softlayer Contact
by Aaron Atac 16 Jan '25

16 Jan '25

Seeking AS36351 Softlayer contact -Aaron

1 0

RE: cloudflare timeout errors (from edge itself)
by Dmitry Sherman 16 Jan '25

16 Jan '25

Funny thing is that cloudflare so far didn’t solve it and closed the case. We tried changing routes didn’t help. Nobody answers from their side Dmitry Sherman Interhost Networks T: +972.74.702.9881 M: +972.54.318.1182 E: dmitry(a)interhost.net<mailto:dmitry@interhost.net> W: interhost.co.il<https://www.interhost.co.il/> [Logo]<https://www.interhost.co.il/> From: Dmitry Sherman Sent: Wednesday, 1 January 2025 23:05 To: NANOG <nanog(a)nanog.org> Subject: cloudflare timeout errors (from edge itself) Hello, Anyone from CloudFlare? I have timeout errors from cloudflare servers (not from origin like 520) but from cloudflare itself, randomally everyday for 10 minutes for many domains under the account in same time. Thanks Dmitry

1 0

** Keynote: Q&A With Google Cloud’s Freund on ‘AI-Powered Network 5.0’ + More!
by Nanog News 16 Jan '25

16 Jan '25

*** Keynote: Q&A With Google Cloud’s Freund on ‘AI-Powered Network 5.0’* ------------------------------------------------------------ *Yun Freund will Present “AI-Powered Network 5.0 – A Paradigm Shift” and Usher in “A New Era of Possibilities”* NANOG caught up with Freund to explore how AI is transforming the networking industry, paving the way for smarter, more efficient, and scalable infrastructures—and what this means for the NANOG community. *READ MORE <https://nanog.org/stories/articles/nanog-93-keynote-insights-qa-with-vp-goo…>* ( https://nanog.org/stories/articles/nanog-93-keynote-insights-qa-with-vp-goo… ) *** Check out NANOG's New IPv6 Clinic* ------------------------------------------------------------ Clinic to ft. AWS Experts Leading Presentations, + a Hands-on Workshop, and an Interactive Whiteboarding Session The NANOG IPv6 on AWS Clinic is a free, in-person event designed to help our community explore the possibilities of IPv6 in the cloud. *SEE MORE <https://nanog.org/events/n93-ipv6clinic-waitlist/>* ( https://nanog.org/events/n93-ipv6clinic-waitlist/) *** Still Time to Register for Hackathon!* ------------------------------------------------------------ *Hackathon Intro/Infrastructure Tutorial/Team Formation Begins Friday (31 Jan.) Virtually* *Theme: Put your sleuthing skills to the test! *The N93 Hackathon will focus on Problem-Solving/Troubleshooting Competitions. Don't wait. Register now! *SEE MORE* <https://nanog.org/events/nanog-93-hackathon/> ( https://nanog.org/events/nanog-93-hackathon/) *** Mark Your Calendar! Don’t Miss the Upcoming NANOG Socials* ------------------------------------------------------------ *Foster Important Relationships in a Relaxed, Casual Environment* N93 is full of exceptional networking opportunities. Be sure to check the schedule and add them to your calendar today! * SEE MORE* <https://nanog.org/events/nanog-93/socials/> ( https://nanog.org/events/nanog-93/socials/) *** Stay Connected* ------------------------------------------------------------ http://www.facebook.com http://www.instagram.com/nanog_org/ http://www.linkedin.com/company/nanog/ https://www.twitter.com/nanog/ http://nanog.org

1 0

Looking for Peering Contact at AS16509
by Xinhao Luo 16 Jan '25

16 Jan '25

Hi, I'm trying to connect with someone responsible for managing North American IXP at AS16509. Greatly appreciate if an appropriate contact could kindly reach out to me off-list. Previously have attempted to reach out via the email address(peering-amer(a)amazon.com) listed on peering.aws website on two occasions but haven’t been successful in establishing contact. Kind Regards, Xinhao Luo

1 0