- NANOG - lists.nanog.org

New c-nsp, j-nsp, a-nsp, etc mailing lists
by Drew Weaver 20 Jan '26

20 Jan '26

I was a big fan of the *-nsp(a)puck.nether.net<mailto:*-nsp@puck.nether.net> mailing lists that now seem to be completely gone without any indication of whether or when they might return. I've been considering just setting up new ones. Please email me off-list if you think this might be useful. Thanks, -Drew

15 25

TORNOG 1 -- Call for Proposals
by Mark Prosser 20 Jan '26

20 Jan '26

Hello NANOG community, Our little community NOG, here in Toronto, is growing. This year we are hosting our first ever full day conference on April 13th, 2026. We would like to welcome folks from far & wide to submit proposals and bring content to operators within our region. The Proposal window opened today. It will be open until EOD (23:59:59 EDT) on March 6th, 2026. We are looking for technical or "meta" talks on networking, automation, and observability. Yet, we also welcome our infrastructure peers to discuss their perspectives on the network. Talks can be 10 minutes, 30 minutes, or 45 minutes in length (technical tutorial / deep dives). Please provide your abstract, speaker bio (optional), and preferred talk length. Slides are not required but appreciated. The theme of TORNOG 1 is: "Stories from Regional Operators" Talks that will be regional to the Toronto / Ontario area will be highly considered. But we would also consider other regional stories from across Canada, and beyond, that consider their story useful to operators in the Toronto area. However, this is just a theme. Talks on any subject, that are not marketing focused, will be considered. Some topics to consider: - Network Automation - Observability & Telemetry - Network Security - Cloud Networking - Career Development in Networking - Diversity & Inclusion in Tech - Emerging Technologies in Networking - Segment Routing / Traffic Engineering - AI & Machine Learning in Networking - Case Studies / Postmortems Please sends you talks to talks(a)tornog.ca or follow the link at: https://tornog.ca/events/tornog-1/proposals/ I wish you all a wonderful 2026, full of peace & prosperity. We are also looking for Sponsors for TORNOG 1. Please reach out to us at sponsors(a)tornog.ca to receive details on our propspectus. We would also appreciate proposals from organizations willing to collaborate with us on workshops -- free with base ticket purchase -- on April 14th, 2026. We hope this would add value for operators traveling into Toronto or clearing their calendar to participate in our community. Some of the TORNOG team will be at NANOG96, if you'd like to learn more over a beer or an in-N-out burger. In solidarity, Mark Prosser Designated TORNOG Lead & Network Operator Advocate /* P.S. -- I have used my BDFL powers to price our tickets at a level I believe is accessible to operators from many walks of life; however, if you feel you the price is out of reach for you, please do not hesitate to reach out & I will do my best to make an accommodation for you. */

1 0

Optimizing Singapore peering?
by Landy Bible 19 Jan '26

19 Jan '26

Hey NANOG, I realize this is "NA" NOG list, but I assume I'm not the only one here who is operating a global network. Context: we have a dozen or so PoPs around the world to serve our load balancer product. We're using continent-specific prefixes to run anycast for this. We are on at least one IX at each location, and use Cogent as our primary transit provider. We'd like to add a real Tier 1 provider at each pop in the future, but In general, this all works ok right now. However, Singapore is a problem. We're on SGIX, but we're seeing a rather high percentage of traffic that originates in Singapore entering our Tokyo PoP instead. Google Cloud in particular is REALLY bad, with application latency testing approaching nearly 1 second, when our typical global latency is under 100ms on an end to end test. Other SG clouds are bad, but not THAT bad. My question to the list here is... for those of you who also operate in Singapore... what would you suggest we do to improve things here? We're looking at adding Arelion or NTT transit in APAC, but we're also trying to get PNIs (or even full IP transit) to the big Singapore networks like SingTel, SingNet, and StarHub, but we haven't had any luck yet. Perhaps we just don't know the right people. From a business perspective our primary concern is latency for our big customers who are hosted on the clouds in the area, but I don't want to just ignore our other customers who aren't in the cloud. Based on my research thus far, my gut says getting transit from Arelion is probably my best "bang for buck" move, but I'm wondering if any of you have any insights or wisdom to share about Singapore or APAC in general. Thanks All, Landy AS62902

6 5

Weird routing pattern - Atlanta device hitting Argentine ISP + unknown EU endpoint
by Intergalactic Auditor 18 Jan '26

18 Jan '26

Hey NANOG, Seeing some odd routing from an Atlanta device that seems to lack logic to say the least. Thought I'd shed some light on it.... Expected: Apple infrastructure (17.x.x.x) Actual destinations: - 109.1.2.1 (SFR France, INFRA-SBT, abuse(a)gaoland.net) - 200.3.10.2 (INTERWEB-DAIREAUX Argentina, 200.3.10.0/23) - 67.1.2.1 (CenturyLink) - 184.0.0.13 (CenturyLink) - 136.3.5.1 (AWS) Pattern: TLS 1.3, 02:00-03:30 local, multiple clients Geographic spread makes no sense (EU + small Argentine ISP from US). Possible C2/exfil. Worth checking your flows for 109.1.0.0/17 and 200.3.10.0/23 from non-EU/LACNIC sources. - Joseph II

2 3

ISP Operators AISURU/Kimwolf botnet
by Corey Smith 18 Jan '26

18 Jan '26

I would appreciate if any ISP Operators could help some of the smaller ISP like us in stopping the traffic from these new Malware infected customers that have devices with Aisiura/Kimwolf botnet, These are Residential Proxies for the most part, but hard to stop. Any help would be greatly appreciated.

15 28

Converting IPFIX flows to columnar format with all IEs - tool recommendations?
by Jonas Muecke 17 Jan '26

17 Jan '26

Hi, I'm looking for recommendations on conversion and long-term storage of raw IPFIX flow data. Specifically, I need to convert IPFIX flows stored in pcap files into a columnar format like Parquet to enable easy and detailed historic analysis that isn't possible with aggregated data. Requirements: - Parse IPFIX from pcap files (including templates) - Preserve ALL information elements, including custom IEs with enterprise PENs - Output enterprise number + IE ID + data (detailed interpretation of the data not needed) - Handle IP fragment reassembly or large IP packets nfdump [1] gets close, but it skips custom IEs. Other tools require replaying the pcaps which risks overflowing buffers, so reading directly from pcap files would be preferred. Has anyone had similar requirements and found a solution? I'm open to multi-step conversions (e.g., via JSON). Long-term I'll capture directly to a better format, but need to process existing pcap archives first. Thanks, Jonas [1] https://github.com/phaag/nfdump -- Jonas Muecke Phd Student, TU Dresden

3 3

Re: ISP Operators AISURU/Kimwolf botnet
by Tom Beecher 17 Jan '26

17 Jan '26

Mike- Should we hold the consumers responsible for their lack of tech knowhow > when corporations with actual ITSEC departments get owned all the time or > is that a total abrogation of responsibility from the people who are taking > the money to provide the service or hardware? So your position here is : Since corporate security folks can't catch everything, end users shouldn't be held responsible for doing anything themselves, and their ISPs should do it? ( Except isn't the ISP the corporate security folks you just said can't catch everything? ) On Sat, Jan 17, 2026 at 12:09 PM Mike Simpson <mikie.simpson(a)gmail.com> wrote: > So where are they getting the malware from if not from their ISP? > > Should we hold the consumers responsible for their lack of tech knowhow > when corporations with actual ITSEC departments get owned all the time or > is that a total abrogation of responsibility from the people who are taking > the money to provide the service or hardware? > > I think the “we aren’t responsible for anything that comes down the pipe > to the end users because doing otherwise will cost $$$ and impact our > revenue” is a stance that shouldn’t hold true anymore. > > I wonder how clearly you advertise the fact in your sales literature that > a user needs to have more technical security knowhow or needs to care more > than fortinet to safely connect to your network. > > That combined with all the reasons why having your users being infested is > bad for you should make you want to do more about it. Being a diseased > network spewing infection is surely seen as bad practice and “it’s the > fault of the users and there is nothing we are willing to do to change > that” shouldn’t be adequate. > > > > On 17 Jan 2026, at 16:26, Tom Beecher <beecher(a)beecher.cc> wrote: > > > >> If you didn’t want your customers being infected then don’t serve them >> malware and then blame them for getting owned and it impacting on your >> network or your upstreams. > > > ISPs aren't 'serving customers malware'. Come on. > > There is a shared responsibility here. ISPs need to take reasonable > precautions to block bad, while also ensuring that users can use the access > they provide in the ways they chose to do so. End users need to have a > basic level of understanding that the 'naked' internet is a nasty place, > and many network enabled devices are poorly designed, so having some level > of network security is important. > > > > On Sat, Jan 17, 2026 at 9:23 AM Mike Simpson via NANOG < > nanog(a)lists.nanog.org> wrote: > >> Again tho. >> What does it matter to the customer. It’s not impacting on their bottom >> line. They are used to fairly rubbish service for a huge multitude of >> reasons so their bandwidth being a bit slashdotted doesn’t matter to them. >> That’s why it’s a ddos. >> >> The only reason they got infected wasn’t their fault. It’s the fault of >> every company that believes that a eula is the end of their liability. >> >> If you didn’t want your customers being infected then don’t serve them >> malware and then blame them for getting owned and it impacting on your >> network or your upstreams. >> >> This is something that should have been sorted out after nimda but that >> wouldn’t have boosted shareholder value apparently. >> >> Your users aren’t aware that it’s not safe to plug stuff into the network >> you provide in the same way that they would expect a firewall not to get >> them owned or that a VPN device would be safe to use. >> >> -this is our fault, our failing, and we need to stop our knee jerk victim >> shaming and do better. >> >> > On 17 Jan 2026, at 12:49, Mel Beckman <mel(a)beckman.org> wrote: >> > >> > Mike, >> > >> > I agree with you where ISPs choose insecure CPE and force their >> customers to use it. But in the case of AISURU, It’s not the CPE causing >> the problem, it’s the customer’s buggy android-based IoT. >> > >> > -mel >> > >> >> On Jan 17, 2026, at 4:16 AM, Mike Simpson <mikie.simpson(a)gmail.com> >> wrote: >> >> >> >> “immediately recognize any they own, which will drive home the point >> that this is their problem” >> >> >> >> That’s some grade A victim blaming bs there. >> >> >> >> “The rubbish CPE that we forced you to have is now owned and it’s >> upsetting our eyeballs only peering arrangements so you need to sort it out” >> >> >> >> ISPs are only not accountable legally for the content of the packets >> they transport. That doesn’t mean they are not responsible for the terrible >> routers they give out. >> >> >> >> Your customers in the main don’t care as they are used to flaky >> internet service. It’s the problem of the ISP as it only really impacts on >> them in an aggregated form so as that’s where the pain is, that’s who is >> “it” for solving it. >> >> >> >> -don’t hand out cheap pos un-updatable CPE or do (shareholder value/ >> enshittification) and accept the consequences with good grace. >> >> >> >> >> >> >> >>>> On 17 Jan 2026, at 02:10, Mel Beckman via NANOG < >> nanog(a)lists.nanog.org> wrote: >> >>> >> >>> immediately recognize any they own, which will drive home the point >> that this is their problem >> _______________________________________________ >> NANOG mailing list >> >> https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SAEZI4V… > >

1 0

Re: ISP Operators AISURU/Kimwolf botnet
by Mel Beckman 17 Jan '26

17 Jan '26

“Where did I get the bad tacos from if not the cab driver?” You are being willfully ignorant now. Have a good day. -mel via cell On Jan 17, 2026, at 9:09 AM, Mike Simpson <mikie.simpson(a)gmail.com> wrote: So where are they getting the malware from if not from their ISP? Should we hold the consumers responsible for their lack of tech knowhow when corporations with actual ITSEC departments get owned all the time or is that a total abrogation of responsibility from the people who are taking the money to provide the service or hardware? I think the “we aren’t responsible for anything that comes down the pipe to the end users because doing otherwise will cost $$$ and impact our revenue” is a stance that shouldn’t hold true anymore. I wonder how clearly you advertise the fact in your sales literature that a user needs to have more technical security knowhow or needs to care more than fortinet to safely connect to your network. That combined with all the reasons why having your users being infested is bad for you should make you want to do more about it. Being a diseased network spewing infection is surely seen as bad practice and “it’s the fault of the users and there is nothing we are willing to do to change that” shouldn’t be adequate. On 17 Jan 2026, at 16:26, Tom Beecher <beecher(a)beecher.cc> wrote: If you didn’t want your customers being infected then don’t serve them malware and then blame them for getting owned and it impacting on your network or your upstreams. ISPs aren't 'serving customers malware'. Come on. There is a shared responsibility here. ISPs need to take reasonable precautions to block bad, while also ensuring that users can use the access they provide in the ways they chose to do so. End users need to have a basic level of understanding that the 'naked' internet is a nasty place, and many network enabled devices are poorly designed, so having some level of network security is important. On Sat, Jan 17, 2026 at 9:23 AM Mike Simpson via NANOG <nanog(a)lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Again tho. What does it matter to the customer. It’s not impacting on their bottom line. They are used to fairly rubbish service for a huge multitude of reasons so their bandwidth being a bit slashdotted doesn’t matter to them. That’s why it’s a ddos. The only reason they got infected wasn’t their fault. It’s the fault of every company that believes that a eula is the end of their liability. If you didn’t want your customers being infected then don’t serve them malware and then blame them for getting owned and it impacting on your network or your upstreams. This is something that should have been sorted out after nimda but that wouldn’t have boosted shareholder value apparently. Your users aren’t aware that it’s not safe to plug stuff into the network you provide in the same way that they would expect a firewall not to get them owned or that a VPN device would be safe to use. -this is our fault, our failing, and we need to stop our knee jerk victim shaming and do better. > On 17 Jan 2026, at 12:49, Mel Beckman <mel(a)beckman.org<mailto:mel@beckman.org>> wrote: > > Mike, > > I agree with you where ISPs choose insecure CPE and force their customers to use it. But in the case of AISURU, It’s not the CPE causing the problem, it’s the customer’s buggy android-based IoT. > > -mel > >> On Jan 17, 2026, at 4:16 AM, Mike Simpson <mikie.simpson(a)gmail.com<mailto:mikie.simpson@gmail.com>> wrote: >> >> “immediately recognize any they own, which will drive home the point that this is their problem” >> >> That’s some grade A victim blaming bs there. >> >> “The rubbish CPE that we forced you to have is now owned and it’s upsetting our eyeballs only peering arrangements so you need to sort it out” >> >> ISPs are only not accountable legally for the content of the packets they transport. That doesn’t mean they are not responsible for the terrible routers they give out. >> >> Your customers in the main don’t care as they are used to flaky internet service. It’s the problem of the ISP as it only really impacts on them in an aggregated form so as that’s where the pain is, that’s who is “it” for solving it. >> >> -don’t hand out cheap pos un-updatable CPE or do (shareholder value/ enshittification) and accept the consequences with good grace. >> >> >> >>>> On 17 Jan 2026, at 02:10, Mel Beckman via NANOG <nanog(a)lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: >>> >>> immediately recognize any they own, which will drive home the point that this is their problem _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SAEZI4V…

1 0

Snapdragon X65 baseband buffer overflow - potential for mass device DoS
by Intergalactic Auditor 17 Jan '26

17 Jan '26

Disclosing for the NOCs at war everyday. Buffer overflow in Qualcomm X65 baseband Issue: SDM state transition → unchecked array index → baseband deadlock → forced reboot Timeline: 9ms to error, 2.3s to crash Trigger: Potentially via 5G/satellite signal Observed events: 2026-01-10, 01-11, 01-14 ~06:00 EST Monitor for: - Clustered device crash reports in narrow time window - "No Service" complaints with normal network metrics - Baseband watchdog resets (rst wdog) Technical: https://github.com/0verdu/X65_BufferOverflow Contact: Keybase: justthemessenger

1 1

Agenda is Published! ** [Video] Experience a NANOG Conference + Q+A with Meta's Omar Baldonado
by Nanog News 16 Jan '26

16 Jan '26

*** NANOG 96 Agenda is Published!* ------------------------------------------------------------ *Sync Your Calendars Now and Never Miss a Talk!* The full NANOG 96 agenda is live. Explore speakers and session abstracts, then view, download, or sync it straight to your calendar. *LEARN MORE* (https://nanog.org/events/nanog-96/agenda/) *** [Video] Experience a NANOG Conference* ------------------------------------------------------------ *See What all the Fuss is About: Watch Highlights, Hear from Attendees + More* You might see yourself in this video! Watch moments from NANOG 95: the Women in Tech “Superstar” event, the NANOG Social at Six Flags Over Texas, and real hallway conversations. Hear it straight from attendees and see what sets NANOG apart. Feeling the FOMO? Register Now for N96! ( https://nanog.org/events/nanog-96/register/) Same unscripted conversations, real breakthroughs, and technical depth you can’t fake or sell. *Trying to explain NANOG to a friend?* Send them this video. ( https://www.youtube.com/watch?v=Xh9Vfdv7N7Q&list=PLO8DR5ZGla8hP_Yyt5cz9o7xP… ) *WATCH NOW* (https://nanog.org/stories/nanog-tv/nanog-95-recap/) *** Inside a N96 Keynote: Q+A with Meta's Omar Baldonado* ------------------------------------------------------------ *When AI Hits the Network: What Meta Learned the Hard Way* NANOG recently caught up with Baldonado for a closer look at his upcoming Keynote “AI Data Center Networking: Lessons from Meta’s Evolution.” Attendees can expect a candid look at Meta’s evolution, from early design assumptions that turned out to be the most wrong, to the cultural shifts required when “everything that isn't a GPU-local error appears to be a network error.” Check out the interview and then show up ready with your own questions. *LEARN MORE *( https://nanog.org/stories/articles/when-ai-hits-the-network-what-meta-learn… ) *** Don’t Miss the Community IXP BoF (Birds of a Feather) at N96!* ------------------------------------------------------------ If You Run a Community Internet Exchange Point (IXP) or Curious About Starting One —You Need to be Here! We’ll swap stories, share lessons learned, and talk about what’s working (and what we wish we’d known) in building successful IXPs. Commercial IXPs are welcome to join the BoF, but the focus will be on building up community-based IXPs. Have a great BoF idea for a future meeting? Submit it below. *SUBMIT NOW* (https://nanog.org/program/call-presentations/) *** 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