Pith. sign in

REVIEW 3 major objections 5 minor 57 references

Network-level Censorship Attacks in the InterPlanetary File System

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that a single malicious autonomous system can censor most live IPFS content for most requesters, because IPFS providers and resolvers are concentrated in a few weakly protected cloud prefixes.

desk verdict First AS-level censorship study of IPFS, with solid measurement and simulation work; the 'single malicious AS' headline overstates what the per-CID max metric actually shows. read the letter →

arxiv 2509.06626 v1 pith:UQRDXBAI submitted 2025-09-08 cs.CR cs.NI

Jan Matter , Muoi Tran This is my paper · ORCID
classification cs.CRcs.NI
keywords IPFSBGPhijackingcensorshipautonomoussystemscontentavailabilityRPKIdecentralizedstorageroutingattacks
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

IPFS was built as a decentralized, censorship-resistant file system, but its live network has drifted toward concentration: most content is stored and resolved by a small set of nodes sitting in cloud-provider prefixes. The paper argues that this concentration turns ordinary routing-plane attacks into a censorship lever. Simulating passive interception and BGP hijacking against 3,000 content identifiers (CIDs) on the measured IPFS topology, it finds that a single malicious autonomous system (AS) can block more than 57% of requesters from 75% of the collected CIDs, and that hijacking about 62 prefixes already reaches 70% of maximal effectiveness. The paper further shows that spreading content across about 80 well-distributed server nodes, or adding backup providers on RPKI-protected max-length prefixes, cuts the achievable interception rate to roughly 20%. If the simulation reflects reality, any well-connected AS—an ISP, transit provider, or nation-state operator—could selectively deny IPFS content at scale.

What carries the argument

The mechanism is the CID retrieval chain and its routing-plane weak points. Retrieving a CID involves three contact sets: Bitswap peers that cache the block, DHT resolver nodes holding provider records, and the content providers themselves. The adversary maps all three for each CID, then uses BGP hijacking or passive interception to cut the requester's routes to them. The simulation's engine is an AS-level routing model that computes shortest-path routing trees over business relationships and classifies every provider prefix by RPKI status, where unprotected and short-prefix entries are hijackable by any AS and RPKI max-length entries only by a closer AS. The greedy prefix-selection count (62 prefixes for 70% effectiveness) and the countermeasure simulations (replication fraction versus interception rate) follow from the same model.

What would settle it

Run a controlled live test: from a test AS, announce a hijack of one of the provider prefixes the simulation marks as vulnerable for a known set of CIDs, then measure retrieval success from distributed IPFS requesters over several days; if fewer than half the simulated requesters actually fail to retrieve the content, the model's upper-bound estimate is too high. Complement this with BGP route-collector data showing that operators' local preferences and filters divert the announced route back to the legitimate path.

Watch

Extended reading notes

Core claim

The central claim is that IPFS censorship does not require an attack on IPFS itself; it can be done by attacking the Internet routing that carries IPFS traffic. Because content providers and the DHT resolvers that map CIDs to providers are concentrated in a few ASes and IP prefixes, and because most of those prefixes are not protected at RPKI max-length, an adversary controlling one AS can drop or hijack the connections requesters need. On the paper's measurements, passive interception alone blocks fewer than 20% of requesters for most CIDs, whereas BGP hijacking achieves roughly 70% blockage for most CIDs, and the combined attack lets one AS block 75% of the collected content for more than 57% of requester nodes. Only 0.5–8% of CIDs can be blocked for every requester; the rest leak through some provider or resolver. The paper also claims that the defenses it simulates—global randomized collaborative pinning plus RPKI-hardened backup providers—can reduce the maximal interception rate to around 20%.

Load-bearing premise

The attack numbers rest on the assumption that real Internet routing behaves like the simplified shortest-path model used in the simulation; if operators filter hijacked announcements or prefer other routes in practice, the real blockage rates will be lower than reported.

Editorial extensions

If this is right

  • An ISP or transit provider that controls a single well-connected AS can deny a majority of requesters access to the majority of live IPFS content without touching DNS or any IPFS software.
  • Because 62 hijacked prefixes buy 70% of maximal effectiveness, the attack is cheap enough for a well-resourced actor to run continuously, not just as a one-off disruption.
  • Fully blocking a specific CID is hard (only 0.5–8% of CIDs were blockable from all requesters), so targeted censorship is easier than blanket censorship.
  • Replicating popular content to roughly 80 distributed server nodes, about 0.5% of the measured server population, caps the best single-AS interception rate at about 20%.
  • Adding at least one provider on an RPKI-protected max-length prefix makes a CID effectively unhijackable in the simulation, as seen with the three IPFS cluster projects tested.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The requester set is limited to observable IPFS server nodes; real end users behind gateways and client nodes may face different, possibly higher, blockage, since gateways concentrate many consumers and are weighted equally here.
  • Because the paper's own model treats route selection as shortest-AS-path with no local preferences or operator filtering, the 75% and 57% figures are upper bounds; live deployments with RPKI filtering and hijack mitigation would likely show lower, but still non-trivial, rates.
  • A natural extension is to weight requesters by served users and to test the greedy prefix-selection against live BGP data, which would tell whether the top prefixes are also the ones an operator would notice hijacking.
  • The collaborative-pinning result suggests a protocol-level default: IPFS could replicate popular CIDs to a small random set of well-distributed server nodes automatically, without waiting for providers to opt in.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper studies network-level censorship of IPFS content via passive BGP interception and active BGP hijacking. The authors collected 3,000 CIDs from the live IPFS network using Bitswap monitoring, crawled IPFS server nodes to build a requester set, and simulated attacks over CAIDA-based AS topology and RPKI classification. The main claims are that 0.5–8% of CIDs can be fully blocked from all requesters, that a single malicious AS can block more than 57% of requesters for about 75% of CIDs, and that hijacking only 62 IP prefixes achieves roughly 70% of the full attack effectiveness. The paper also proposes and simulates countermeasures based on IPFS clusters and global collaborative pinning, reporting that replicating content to about 0.5% of server nodes limits the strongest attacker to a roughly 20% interception rate.

Significance. If the headline results hold, this would be the first systematic analysis of BGP-based routing attacks against IPFS, extending prior work on Bitcoin, Ethereum, and other decentralized systems to an important Web3 storage layer. The paper's strengths include real-world CID collection, the use of externally sourced CAIDA topology and RPKI data, and the explicit acknowledgment that the model provides an upper bound on realistic attacker effectiveness. The countermeasure analysis is a useful first step, although its protocol-level incentive questions are only sketched. However, the central quantitative claim in the abstract is not currently demonstrated by the presented experiments because of an aggregation issue in how the per-CID attacker success rates are combined; the contribution is significant but needs a re-analysis of the headline metric before it can be accepted.

major comments (3)
  1. [§4.2 / Abstract / Fig. 8] The headline claim that 'a single malicious AS can censor 75% of the IPFS content for more than 57% of all requester nodes' is not supported by the presented evaluation. Figure 8 plots, for each CID, the maximal success rate over the 100 candidate attacker ASes, so the maximizing AS may differ across CIDs; the paper does not report the fixed-AS analogue (for example, for each AS, the fraction of CIDs for which that AS blocks more than 57% of requesters). Figure 9 reports a different quantity, the average portion of CID×requester pairs per AS (67% for AS174), which does not by itself establish the headline threshold. In addition, Figure 8 is labeled 'dataset 1' only, while the abstract presents the result as if it covers all three datasets. Please provide the fixed-AS distribution for each dataset and revise the abstract and Section 4.2 to match the evidence.
  2. [§4.3 / Abstract] The statement that 'a small set of only 62 hijacked prefixes' reaches '70% of the full attack effectiveness' is not substantiated in the text. Section 4.3 describes a greedy prefix-selection algorithm and Figure 11 shows average success-rate curves, but neither the number 62 nor a definition of 'full attack effectiveness' appears in the narrative. Please specify the target metric (e.g., average over CIDs of the fraction of blocked requesters), the greedy algorithm's stopping rule, and how the exact 62-prefix figure is derived from Figure 11 or the underlying data.
  3. [Appendix 8.2] The appendix's list of the 'top 100' attacker ASes contains duplicate entries (e.g., AS1221 appears at ranks 27 and 73, AS2635 at ranks 28 and 74, and AS16509 at ranks 39 and 85, among many others). If these duplicates are used in the simulation, the attacker set comprises fewer than 100 distinct ASes; if they are not used, the appendix should list unique ASes. This point must be clarified and corrected because the attacker set is a core input to the reported effectiveness numbers.
minor comments (5)
  1. [Abstract / §1] The phrase 'all requester nodes' should be qualified as 'all IPFS server nodes in the crawled topology' to match the actual requester set; the limitation is acknowledged in Section 6 but should be reflected in the abstract and introduction.
  2. [§3.2] The sentence 'we considered thecid.contactdomain' should read 'the cid.contact domain'.
  3. [§5.2 / Fig. 12] The caption of Figure 12 states 'Mean of 5 measured samples'; please clarify in the text how the five samples were drawn and whether the plotted curve is the maximum over the 100 ASes or an average, as the y-axis label says 'Maximally intercepted Requester Fraction'.
  4. [§4] The paper says the full IPFS crawl takes about 5 minutes and that two crawls were executed on July 12 and 13, 2025. Please clarify whether the requester snapshot is contemporaneous with the CID datasets collected in July 2025, and if not, discuss the potential effect of topology drift on the results.
  5. [References] References [8] and [28] contain 'Accessed: [Insert Date of Access]' placeholders that should be filled in.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the attack numbers are forward-simulation outputs.

full rationale

The central results—75% of CIDs blockable for over 57% of requesters, the full-blockage fractions, and the 62-prefix cost point—are produced by a forward simulation whose inputs are external measurements: live CID samples collected via Bitswap monitoring, IPFS server-node crawls, CAIDA AS-relationship and IXP topology data, RPKI status lookups, and the stated attacker model of a single AS using simplified shortest-AS-path BGP. No fitted parameter or reused equation is presented as the reported prediction. The BGP path-computation implementation and the simplified-routing validation are cited from the authors' earlier work ([55], [53]), but those citations supply a generic routing-tree algorithm and a modeling assumption validated against different targets (Lightning and cryptocurrency routing attacks), not the IPFS blocking rates themselves; they are independent support rather than a self-referential premise. Section 6 explicitly calls the analysis 'rather an upper bound' and discloses the simplified BGP routing assumptions; that is a limitation on external validity, not a circular step. The possible mismatch between the per-CID maximum used in Figure 8 and the Abstract's wording 'a single malicious AS' is an aggregation and interpretation concern, not a case where the derivation reduces to its own inputs by construction. Since no circular step can be exhibited from the paper's own equations or self-citation chain, the appropriate finding is no significant circularity.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The paper's central numbers are forward simulation outputs rather than fitted constants, so the free-parameter list is short. The load-bearing axioms are the simplified BGP model and the requester-set approximation, both explicitly flagged by the authors as limitations. No new physical or protocol entities are invented; the proposed global collaborative pinning is a countermeasure protocol, not an entity used by the attack.

free parameters (4)
  • Attacker AS set (top 100 CAIDA-ranked ASes)
    Section 4 limits the adversary to the 100 highest-ranked ASes, which bounds the achievable blockage rates and excludes less connected but possibly locally relevant attacker ASes.
  • Resolver lookup count = 30 peers
    Algorithm 1 looks up 30 DHT peers per CID (20 default providers plus a 10-peer safety margin); the enumerated attack surface depends on this choice.
  • CID selection scoring weights
    Section 3.2 selects CIDs using a weighted sum where each peer is weighted inversely to its frequency across other CIDs. The heuristic affects which content is included in the three datasets.
  • Requester scope (IPFS server nodes only)
    Section 4 deduplicates crawled IPFS server nodes by IP address and excludes IPFS client nodes, which cannot be observed by the crawler. The headline requester percentages are conditional on this scope.
assumptions (6)
  • domain assumption Simplified BGP route selection: shorter AS paths are preferred, maintaining customer-provider and peer-to-peer relationships, without local preference or BGP communities.
    Section 3.1 states this simplification 'has been shown to accurately approximate the real routing of the internet for analysis of routing-based attacks.' The simulated hijack success rates depend directly on this model.
  • domain assumption IPFS topology is static during the measurement and attack window.
    Section 3.1 assumes topology drift is negligible. The reconnaissance and censorship phases are analyzed as a single snapshot, not over time.
  • domain assumption Provider records are replicated to the k=20 peers whose IDs are closest to the CID in XOR distance.
    Section 2.2 describes this as an IPFS protocol property. The identification of resolver prefixes in Algorithm 1 relies on this mechanism.
  • domain assumption The CAIDA AS relationship and IXP datasets used by the BGP simulator accurately represent Internet topology.
    Section 3.3 builds routing trees on CAIDA datasets; errors in AS business relationships would change which ASes intercept traffic.
  • domain assumption RPKI status retrieved from irrexplorer determines hijackability into the four categories used in the simulation.
    Section 3.3 assigns prefixes to RPKI categories and derives hijack success rules from those categories. RPKI deployment or ROA changes would alter the results.
  • domain assumption The crawled IPFS server node set represents the relevant content requesters.
    Section 4 and Section 6 acknowledge that client nodes and NATed nodes are not captured and that gateways are not weighted by consumer counts. The 57% requester figure is defined over this set.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Network-level Censorship Attacks in the InterPlanetary File System." pith.science (2026). https://pith.science/paper/UQRDXBAI

@misc{pith2026250906626,
  author       = {Pith},
  title        = {Pith review of: Network-level Censorship Attacks in the InterPlanetary File System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UQRDXBAI}},
  note         = {Machine review of arXiv:2509.06626}
}
read the original abstract

The InterPlanetary File System (IPFS) has been successfully established as the de facto standard for decentralized data storage in the emerging Web3. Despite its decentralized nature, IPFS nodes, as well as IPFS content providers, have converged to centralization in large public clouds. Centralization introduces BGP routing-based attacks, such as passive interception and BGP hijacking, as potential threats. Although this attack vector has been investigated for many other Web3 protocols, such as Bitcoin and Ethereum, to the best of our knowledge, it has not been analyzed for the IPFS network. In our work, we bridge this gap and demonstrate that BGP routing attacks can be effectively leveraged to censor content in IPFS. For the analysis, we collected 3,000 content blocks called CIDs and conducted a simulation of BGP hijacking and passive interception against them. We find that a single malicious AS can censor 75% of the IPFS content for more than 57% of all requester nodes. Furthermore, we show that even with a small set of only 62 hijacked prefixes, 70% of the full attack effectiveness can already be reached. We further propose and validate countermeasures based on global collaborative content replication among all nodes in the IPFS network, together with additional robust backup content provider nodes that are well-hardened against BGP hijacking. We hope this work raises awareness about the threat BGP routing-based attacks pose to IPFS and triggers further efforts to harden the live IPFS network against them.

Figures

Figures reproduced from arXiv: 2509.06626 by the authors.

Figure 1
Figure 1. High-level overview of routing-based censorship [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Publishing and Retrieving Content in IPFS. The content provider binds the content [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Shows the cumulative distribution function for the [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Shows the cumulative distribution function for the [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Shows the number of unique IP prefixes of all con [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 8
Figure 8. Figure 8: Shows the maximal rate of successfully blocked [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Shows fraction of CIDxRequester pairs that a single [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: The maximal rate of successfully blocked re [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 12
Figure 12. Figure 12: Shows for different fractions of all IPFS server [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 55 canonical work pages

  1. [1]

    Hijacking bitcoin: Routing attacks on cryptocurrencies

    Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. Hijacking bitcoin: Routing attacks on cryptocurrencies. InProc. IEEE S&P, 2017

    work page 2017

  2. [2]

    pyasn: Offline ip to asn lookup tool

    Hadi Asghari and Arman Noroozian. pyasn: Offline ip to asn lookup tool. https://pypi.org/project/pya sn/, 2023. Python module for fast offline and historical IP-to-ASN lookups. Developed during PhD research on cybersecurity measurements

    work page 2023

  3. [3]

    Monitoring data requests in decentralized data storage systems: A case study of ipfs

    Leonhard Balduf, Sebastian Henningsen, Martin Florian, Sebastian Rust, and Björn Scheuermann. Monitoring data requests in decentralized data storage systems: A case study of ipfs. InProceedings of the IEEE 42nd International Conference on Distributed Computing Sys- tems (ICDCS), 2022. Accepted at ICDCS 2022

    work page 2022

  4. [4]

    The Cloud Strikes Back: Investigating the Decentralization of IPFS

    Leonhard Balduf, Navin V . Keizer, Maciej Korczy´nski, George Pavlou, Michał Król, Onur Ascigil, and Björn Scheuermann. The cloud strikes back: Investigating the decentralization of ipfs. https://arxiv.org/abs/23 09.16203, 2023. arXiv:2309.16203 [cs.NI]

    work page Pith review arXiv 2023

  5. [6]

    Bamboozling certificate authorities with BGP

    Henry Birge-Lee, Yixin Sun, Anne Edmundson, Jennifer Rexford, and Prateek Mittal. Bamboozling certificate authorities with BGP. InProc. USENIX Security, 2018

    work page 2018

  6. [7]

    Irr explorer

    DashCare BV and Stichting NLNOG. Irr explorer. ht tps://irrexplorer.nlnog.net , 2025. Developed to visualize routing, IRR, and RPKI status for network resources

    work page 2025

  7. [8]

    As rank: Ranking autonomous systems

    CAIDA. As rank: Ranking autonomous systems. ht tps://asrank.caida.org/, 2023. Accessed: [Insert Date of Access]

    work page 2023

  8. [9]

    AS Relationships Dataset

    CAIDA. AS Relationships Dataset. https://www.ca ida.org/catalog/datasets/as-relationships/ , 2025

    work page 2025

Show all 57 references
  1. [10]

    Cen- tralization in the decentralized web: Challenges and opportunities in ipfs data management.Proceedings of the ACM Web Conference (WWW), April 2025

    Ruizhi Cheng, Yuetong Wu, Ashish Kundu, Hugo Lat- apie, Myungjin Lee, Songqing Chen, and Bo Han. Cen- tralization in the decentralized web: Challenges and opportunities in ipfs data management.Proceedings of the ACM Web Conference (WWW), April 2025

    2025

  2. [11]

    Sybil at- tack strikes again: Denying content access in ipfs with a single computer

    Thibault Cholez and Claudia-Lavinia Ignat. Sybil at- tack strikes again: Denying content access in ipfs with a single computer. InProceedings of the 19th Interna- tional Conference on Availability, Reliability and Secu- rity (ARES), pages 1–7. ACM, July 2024

    2024

  3. [12]

    Cloudflare dns goes down, taking a large piece of the internet with it

    Devin Coldewey. Cloudflare dns goes down, taking a large piece of the internet with it. https://techcrun ch.com/2020/07/17/cloudflare-dns-goes-dow n-taking-a-large-piece-of-the-internet-wit h-it/, July 2020. Accessed: 2025-07-09

    2020

  4. [13]

    Passively measuring ipfs churn and network size

    Erik Daniel and Florian Tschorsch. Passively measuring ipfs churn and network size. In2022 IEEE 42nd Inter- national Conference on Distributed Computing Systems Workshops (ICDCSW), pages 60–65. IEEE, 2022

    2022

  5. [14]

    Accelerating content routing with bitswap: A multi-path file transfer protocol in ipfs and filecoin.San Francisco, CA, USA (2021), 2021

    Alfonso De la Rocha, David Dias, and Yiannis Psaras. Accelerating content routing with bitswap: A multi-path file transfer protocol in ipfs and filecoin.San Francisco, CA, USA (2021), 2021

    2021

  6. [15]

    Cloudflare Disables Access to ‘Pirated’ Content on its IPFS Gateway

    Ernesto Van der Sar. Cloudflare Disables Access to ‘Pirated’ Content on its IPFS Gateway. https://torr entfreak.com/cloudflare-disables-access-t o-pirated-content-on-its-ipfs-gateway-230 324/, 2023

    2023

  7. [16]

    Rout- ing attacks in ethereum pos: A systematic exploration

    Constantine Doumanidis and Maria Apostolaki. Rout- ing attacks in ethereum pos: A systematic exploration. h t t p s : / / a r x i v . o r g / a b s / 2 5 0 5 . 0 7 7 13, 2025. arXiv:2505.07713 [cs.NI]

    2025 arXiv

  8. [17]

    Conman: A connection manipulation- based attack against bitcoin networking

    Wenjun Fan, Sang-Yoon Chang, Xiaobo Zhou, and Shouhuai Xu. Conman: A connection manipulation- based attack against bitcoin networking. InProceedings of the IEEE Conference on Communications and Net- work Security (CNS), pages 101–109. IEEE, 2021

    2021

  9. [18]

    The InterPlanetary Development Platform

    FileBase. The InterPlanetary Development Platform. https://filebase.com/, 2025

    2025

  10. [19]

    As relationships dataset

    CAIDA Center for Applied Internet Data Analysis. As relationships dataset. https://www.caida.org/cata log/datasets/as-relationships/, 2020. Accurate knowledge of AS business relationships is relevant to both technical and economic aspects of the Internet’s inter-domain structu...

    2020

  11. [20]

    In- ternet exchange points (ixps) dataset

    CAIDA Center for Applied Internet Data Analysis. In- ternet exchange points (ixps) dataset. https://ww w.caida.org/catalog/datasets/ixps/ , 2020. Dataset combining information from PeeringDB, Hurri- cane Electric, Packet Clearing House, and GeoNames to provide geographic and m...

    2020

  12. [21]

    Stable internet routing without global coordination.IEEE/ACM TON, 2001

    Lixin Gao and Jennifer Rexford. Stable internet routing without global coordination.IEEE/ACM TON, 2001

    2001

  13. [22]

    How secure are secure interdomain routing protocols? Technical report, Microsoft Research and Yale University, 2010

    Sharon Goldberg and Michael Schapira. How secure are secure interdomain routing protocols? Technical report, Microsoft Research and Yale University, 2010. Full 14 version dated February 23, 2010. Analyzes the effec- tiveness of secure BGP variants against traffic attraction at...

    2010

  14. [23]

    How secure are secure interdo- main routing protocols.ACM SIGCOMM CCR, 2010

    Sharon Goldberg, Michael Schapira, Peter Hummon, and Jennifer Rexford. How secure are secure interdo- main routing protocols.ACM SIGCOMM CCR, 2010

    2010

  15. [25]

    Henningsen, Sebastian Rust, Martin Flo- rian, and Björn Scheuermann

    Sebastian A. Henningsen, Sebastian Rust, Martin Flo- rian, and Björn Scheuermann. Demo: Crawling the ipfs network. InProceedings of the IFIP Networking Conference, pages 679–680. IEEE, 2020

    2020

  16. [26]

    Pretty good bgp: improving bgp by cautiously adopting routes

    Josh Karlin, Stephanie Forrest, and Jennifer Rexford. Pretty good bgp: improving bgp by cautiously adopting routes. InProc. IEEE International Conference on Network Protocols, 2006

    2006

  17. [27]

    Ipfs origins and a new p2p summer (2013–2017)

    Protocol Labs. Ipfs origins and a new p2p summer (2013–2017). https://docs.ipfs.tech/project /history/#ipfs-origins-and-a-new-p2p-summe r-2013-2017, 2023. Accessed: 2025-07-08

    2013

  18. [28]

    IPFS Cluster

    Protocol Labs and Contributors. IPFS Cluster. https: //ipfscluster.io/, 2023. Accessed: [Insert Today’s Date]

    2023

  19. [29]

    Per- formance evaluation of ipfs in private networks

    Omar Abdullah Lajam and Tarek Ahmed Helmy. Per- formance evaluation of ipfs in private networks. In Proceedings of the 2021 4th International Conference on Data Storage and Data Engineering (DSDE), pages 77–84. Association for Computing Machinery, 2021

    2021

  20. [30]

    libp2p.https://docs.libp2p.io, 2025

    libp2p. libp2p.https://docs.libp2p.io, 2025

    2025

  21. [31]

    libp2p. TLS. https://docs.libp2p.io/concepts/ secure-comm/tls/, 2025

    2025

  22. [32]

    RPKI ROV Deployment Reaches Major Milestone

    Doug Madory. RPKI ROV Deployment Reaches Major Milestone. https://manrs.org/2024/05/rpki-rov -deployment-reaches-major-milestone/, 2024

    2024

  23. [33]

    No Justification for Spanish Internet Censorship During Catalonian Referendum

    Jeremy Malcolm. No Justification for Spanish Internet Censorship During Catalonian Referendum. https: //www.eff.org/deeplinks/2017/10/no-justifi cation-spanish-internet-censorship-durin g-catalonian-referendum, 2017

    2017

  24. [34]

    Kademlia: A peer-to-peer information system based on the XOR metric

    Petar Maymounkov and David Mazières. Kademlia: A peer-to-peer information system based on the XOR metric. InRevised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS ’01, pages 53–65, Berlin, Heidelberg, 2002. Springer-Verlag

    2002

  25. [35]

    Multihash

    Multiformats. Multihash. https://multiformats.i o/multihash/, 2025

    2025

  26. [36]

    {Website-Targeted} false content injection by network operators

    Gabi Nakibly, Jaime Schcolnik, and Yossi Rubin. {Website-Targeted} false content injection by network operators. InProc. USENIX Security, 2016

    2016

  27. [37]

    Active sybil attack and efficient defense strategy in ipfs dht.arXiv preprint arXiv:2505.01139, May 2025

    Victor Henrique De Moura Netto, Thibault Cholez, and Claudia-Lavinia Ignat. Active sybil attack and efficient defense strategy in ipfs dht.arXiv preprint arXiv:2505.01139, May 2025

    2025 arXiv

  28. [38]

    Crypto’s File Storage

    Pinata. Crypto’s File Storage. https://pinata.clo ud/, 2025

    2025

  29. [39]

    Total eclipse of the heart – disrupting the inter- planetary file system

    Bernd Prünster, Alexander Marsalek, and Thomas Zef- ferer. Total eclipse of the heart – disrupting the inter- planetary file system. https://arxiv.org/abs/2011 .00874, 2020. arXiv:2011.00874 [cs.CR]

    2011 arXiv

  30. [40]

    A worldwide view of network-level paths to censorship

    Ram Sundara Raman, Prerana Shenoy, Katharina Kohls, and Roya Ensafi. A worldwide view of network-level paths to censorship. InProceedings of the 29th USENIX Security Symposium, pages –. USENIX Association, August 2020

    2020

  31. [41]

    Rfc 4271: A border gateway protocol 4 (bgp-4), 2006

    Yakov Rekhter, Tony Li, and Susan Hares. Rfc 4271: A border gateway protocol 4 (bgp-4), 2006

    2006

  32. [42]

    Three birds with one stone: Efficient partitioning attacks on interde- pendent cryptocurrency networks

    Muhammad Saad and David Mohaisen. Three birds with one stone: Efficient partitioning attacks on interde- pendent cryptocurrency networks. InProc. IEEE S&P, 2023

    2023

  33. [43]

    Artemis: Neutralizing bgp hijacking within a minute.IEEE/ACM TON, 2018

    Pavlos Sermpezis, Vasileios Kotronis, Petros Gigis, Xenofontas Dimitropoulos, Danilo Cicalese, Alistair King, and Alberto Dainotti. Artemis: Neutralizing bgp hijacking within a minute.IEEE/ACM TON, 2018

    2018

  34. [44]

    How much does an IPFS Pinning Service Cost? https://pinata.cloud/blog/how-much-d oes-an-ipfs-pinning-service-cost/, 2023

    Pinata Service. How much does an IPFS Pinning Service Cost? https://pinata.cloud/blog/how-much-d oes-an-ipfs-pinning-service-cost/, 2023

    2023

  35. [45]

    A closer look into ipfs: Accessibility, content, and performance.Proceedings of the ACM on Measurement and Analysis of Computing Systems, 8(2):Article 20, 1–31, June 2024

    Ruizhe Shi, Ruizhi Cheng, Bo Han, Yue Cheng, and Songqing Chen. A closer look into ipfs: Accessibility, content, and performance.Proceedings of the ACM on Measurement and Analysis of Computing Systems, 8(2):Article 20, 1–31, June 2024

    2024

  36. [46]

    What happened? the amazon route 53 bgp hijack to take over ethereum cryptocurrency wallets

    Aftab Siddiqui. What happened? the amazon route 53 bgp hijack to take over ethereum cryptocurrency wallets. https://www.internetsociety.org/blog/2018/ 04/amazons-route-53-bgp-hijack/ , April 2018. Accessed: 2025-07-09

    2018

  37. [47]

    Investigating the impact 15 of ddos attacks on dns infrastructure

    Raffaele Sommese, KC Claffy, Roland van Rijswijk- Deij, Arnab Chattopadhyay, Alberto Dainotti, Anna Sperotto, and Mattijs Jonker. Investigating the impact 15 of ddos attacks on dns infrastructure. InProceedings of the ACM Internet Measurement Conference (IMC), pages 20:1–20:15...

    2022

  38. [48]

    Content censorship in the in- terplanetary file system

    Srivatsan Sridhar, Onur Ascigil, Navin Keizer, François Genon, Sébastien Pierre, Yiannis Psaras, Etienne Riv- ière, and Michał Król. Content censorship in the in- terplanetary file system. InNetwork and Distributed System Security (NDSS) Symposium, San Diego, CA, USA, 2024. Th...

    2024 arXiv

  39. [49]

    RAPTOR: Routing attacks on privacy in Tor

    Yixin Sun, Anne Edmundson, Laurent Vanbever, Oscar Li, Jennifer Rexford, Mung Chiang, and Prateek Mittal. RAPTOR: Routing attacks on privacy in Tor. InProc. USENIX Security, 2015

    2015

  40. [50]

    How I set up my own Autonomous System

    Daryll Swer. How I set up my own Autonomous System. https://blog.apnic.net/2022/07/01/how-i-s et-up-my-own-autonomous-system/, 2022

    2022

  41. [51]

    Threat Actors Rapidly Adopt Web3 IPFS Technology

    Amanda Tanner, Kristopher Bleich, Anthony Galiette, and Joseph Opacki. Threat Actors Rapidly Adopt Web3 IPFS Technology. https://unit42.paloaltonetwo rks.com/ipfs-used-maliciously/, 2023

    2023

  42. [52]

    CIDR Report

    Geoff Huston Tony Bates, Philip Smith. CIDR Report. https://www.cidr-report.org/as2.0/, 2025

    2025

  43. [53]

    Rout- ing attacks on cryptocurrency mining pools

    Muoi Tran, Theo von Arx, and Laurent Vanbever. Rout- ing attacks on cryptocurrency mining pools. InProc. IEEE S&P, 2024

    2024

  44. [54]

    Design and evaluation of ipfs: A storage layer for the decentralized web

    Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ig- nacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, and Yiannis Psaras. Design and evaluation of ipfs: A storage layer for the decentralized web. InProceedings of the ACM SIGCOMM 2022 Conference. ACM, August 2022

    2022

  45. [55]

    Rev- elio: A network-level privacy attack in the lightning network

    Theo von Arx, Muoi Tran, and Laurent Vanbever. Rev- elio: A network-level privacy attack in the lightning network. InProceedings of the 8th IEEE European Symposium on Security and Privacy (EuroS&P), Delft, Netherlands, July 2023. IEEE

    2023

  46. [56]

    The eternal tussle: exploring the role of centralization in{IPFS}

    Yiluo Wei, Dennis Trautwein, Yiannis Psaras, Ignacio Castro, Will Scott, Aravindh Raman, and Gareth Tyson. The eternal tussle: exploring the role of centralization in{IPFS}. InUSENIX NSDI, 2024

    2024

  47. [57]

    Vimpelcom

    Mingshi Wu, Ali Zohaib, Zakir Durumeric, Amir Houmansadr, and Eric Wustrow. A wall behind a wall: Emerging regional censorship in china. InProc. IEEE S&P, 2025. 8.1 Countermeasures - Collaborative IPFS cluster ASes and Prefixes Project Gutenberg (Spanish) ASes: 54825, 12322, 1...

    2025

  48. [2014]

    arXiv:1407.3561 [cs.NI], Draft 3

    arXiv

  49. [2020]

    arXiv:2002.07747 [cs.NI]

    2002 arXiv

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.