Mastodawn

Has anyone thought through the ramifications of SCION adoption (a more secure BGP alternative) with respect to Open Internet access?

Yes, it gives much better, more performant, more robust routing. It seems imposing strong trust controls, regionally (or nationally) managed, on routing would be a big security improvement.

But doesn't it give the nation state an iron hand in who is allowed to route? Does it create risks for the open internet?

https://www.theregister.com/2026/03/17/switzerland_bgp_alternative/

#Internet #Routing #BGP #OpenInternet

Switzerland built a secure alternative to BGP. The rest of the world hasn't noticed yet

Feature: SCION: Proven in banking and healthcare, slow to spread everywhere else

The Register

Ulf Dittmer 7h ago

There is something better, and more secure, than #BGP: SCION. Will the world, or at least Europe, adopt it?

https://www.theregister.com/2026/03/17/switzerland_bgp_alternative/

Switzerland built a secure alternative to BGP. The rest of the world hasn't noticed yet

Feature: SCION: Proven in banking and healthcare, slow to spread everywhere else

The Register

Larvitz

10h ago

Put some information about my Autonomous System, connectivity and peering policy on my website:

https://hofstede.it/as201379.html

#internetrouting #networking #routing #bgp #sovereignty #freebsd #ipv6

AS201379 - Christian Hofstede-Kuhn

Autonomous System 201379. Information, Peering Policy, and Connectivity.

Christian Hofstede-Kuhn

decio 11h ago

Tiens, GG TheReg...

" #Switzerland built a secure alternative to #BGP The rest of the world hasn't noticed yet
SCION: Proven in banking and healthcare, slow to spread everywhere else"
👇
https://www.theregister.com/2025/09/26/salesforce_class_actions/

( https://www.scion.org/about-scion/ )

ce qui rejoins les considerations techniques du OFCS
⬇️
Technology consideration: SCION -PDF, 221 kB, 22.05.2025

#Network

Salesforce facing multiple lawsuits after Salesloft breach

Updated: CRM giant denies security shortcomings as claims allege stolen data used for ID theft

The Register

Larvitz

23h ago

My autonomous System AS201379 is now connected to an Internet Exchange Point (IXP): LocIX in Düsseldorf.

It's already showing up in the global routing table and traffic already starts flowing through the direct links with my peers 🙂

https://bgp.tools/as/201379

Amazing !

#networking #ipv6 #routing #ixp #peering #bgp

GripNews 1d ago

🌗 僅依賴互聯網交換中心（IX）路由伺服器，網絡能走多遠？
➤ 路由伺服器的效率與極限：從數據看網絡連通的真相
✤ https://blog.benjojo.co.uk/post/how-far-can-you-get-with-ix-route-servers
本文探討了僅通過互聯網交換中心（IXP）的路由伺服器（Route Servers）來建立網絡連接的可行性。作者指出，雖然路由伺服器簡化了 BGP 配置並具備強大的安全性優勢，但僅依賴其獲取路由表並不足以支撐完整的網絡連通性。作者通過數據分析發現，即使匯集全球多個交換中心的路由數據，出站路徑覆蓋率僅能達到約 60%，而關鍵的入站流量可達性更低至 14% 左右。這表明雖然路由伺服器在現代網絡架構中扮演重要角色，但要構建一個成熟的網絡，仍需依賴傳統的直連對等（Bilateral Peering）及過境流量（Transit）服務。
+ 這篇文章精準地指出了「依賴路由伺服器」的侷限性。很多新手以為只要接入幾個大 IXP 就能搞定全球路由，卻忽略了入站流量的非對稱性問題。
#網絡工程 #BGP #互聯網交換中心 (IXP) #路由策略

How far can you go with IX Route Servers only?

T_X 3d ago

Yaiy, iEdon's #dn42 map got support for the #BGP #multicast channel!! You can change the channel via the new button in the top right which initially says "ALL".
https://map.iedon.net/

DN42 Realtime Network Map: The easiest way to visualize the DN42 network

The easiest way to visualize the DN42 network. We retrieve MRT dumps from the DN42 GRC and display ASes, their neighbors, and links on this map.

iEdon-Net

John Kristoff 3d ago

Weekend Reads

* Post-quantum RPKI framework
https://arxiv.org/abs/2603.06968
* DNSSEC negative trust anchors
https://quad9.net/news/blog/dnssec-ntas-no-good-compromises/
* AS112 deployment characteristics
https://0x03c0.com/files/pam26-as112-camera-ready-with-notice.pdf
* Geoff Huston on Internet timekeeping
https://www.potaroo.net/ispcol/2026-03/nts.html
* Measuring IX route servers prefix coverage
https://blog.benjojo.co.uk/post/how-far-can-you-get-with-ix-route-servers

#RPKI #DNSSEC #DNS #NTP #BGP

pqRPKI: A Practical RPKI Architecture for the Post-Quantum Era

The Resource Public Key Infrastructure (RPKI) secures Internet routing by binding IP prefixes to authorized Autonomous Systems, yet its RSA foundations are vulnerable to quantum adversaries. A naive swap to post-quantum (PQ) signatures (eg Falcon) is a poor fit for RPKI's bulk model: every relying party (RP) repeatedly fetches and validates the entire global repository, so larger keys and signatures inflate bandwidth and CPU cost, especially during a long dual-stack transition. We present pqRPKI , a post-quantum RPKI framework that pairs a multi-layer Merkle Tree Ladder (MTL) with RPKI objects, customized to relocate per-object verification material from certificates into the Manifest. To update RPKI for Merkle tree based schemes, pqRPKI redesign the RPKI manifest and delegation chain, introduces a ladder-guided sync and bulk-verification workflow that lets validators localize diffs top-down and rebuild trees bottom-up. pqRPKI also preserves current RPKI objects and encodings, supports both hosted and delegated operation, and provides an additive migration path that coexists with today's trust anchors for dual-stack deployment with little size overhead. Implemented as a working publication point (PP) and RPs, we show that pqRPKI reduces repository footprint to 546.8 MB on average (65.5%/83.1% smaller than Falcon/ML-DSA), cuts full-cycle validation to 102.7 s, and achieves 118.3 s end-to-end PP to Router time, enabling sub-2-minute operating cadences with full-repository validation each cycle. Dual-stack deployment with RSA only adds just 3.4% size overhead versus today's RPKI repositories.

arXiv.org

Show thread