[api]

This uses DHTs. How resilient is it against Sybil attacks? Also how does it work under global netsplit conditions, like if someone borks or attacks BGP in such a way that 1/3 of the world is not reachable?

My impression is that DHTs fall down pretty hard under the latter scenario and are also pretty vulnerable to the Sybil scenario if the attacker has enough resources to mount a really serious attack. They're okay for low-value simple stuff that doesn't have much of an intrinsic bounty attached to it (like BitTorrent magnets), but trying to put a "decentralized web" on top of a DHT seems like a scenario where the instant it becomes popular it will get completely shredded for profit (spam, stealing Bitcoin, etc.).

My rule of thumb is that anything designed for serious or large scale use (in other words that might get popular) needs to be built to withstand either a "nation state level attacker" threat model or a "Zerg rush of hundreds of thousands of profit motivated black hats" threat model. The Internet today is a war zone because today you can make money and gain power (e.g. by influencing elections) by messing with it.

[willscott]

For BGP partitions / Significant network outage conditions: You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you. This is better than centralized solutions face at present - e.g. google not being available in China, and isn't too far off from what you might hope.

For Sybils: You've left the attack you're worried about pretty vague. IPFS itself doesn't need to tackle many of the sybil-related issues by being content addressable (so only worrying about availability - not integrity) and not being a discovery platform - so not worrying about spam / influence. For the remaining degradation attacks - someone overwhelming the DHT with misbehaving nodes - there's been a bunch of work in this release looking at how to score peers and figure out which ones aren't worth keeping in the DHT.

[jude-]

> You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you.

This becomes hugely problematic the minute you start using IPNS. On one side of the split, the name `foo` can resolve to `bar`, but on the other side, it resolves to `baz`. If you're trying to impersonate someone, then a netsplit would make it easy for you to do so (barring an out-of-band content authentication protocol, of course).

> You've left the attack you're worried about pretty vague. IPFS itself doesn't need to tackle many of the sybil-related issues by being content addressable (so only worrying about availability - not integrity) and not being a discovery platform - so not worrying about spam / influence.

On the contrary, a Sybil node operator can censor arbitrary content in a DHT by inserting their own nodes into the network that are all "closer" to the targeted key range in the key space than the honest nodes. This can be done by crawling the DHT, identifying the honest nodes that route to the targeted key range, and generating node IDs that correspond to key ranges closer than them. Honest nodes will (correctly) proceed to direct lookup requests to the attacker nodes, thereby leading to content censorship.

Honest nodes can employ countermeasures to probe the network in order to try and see if/when this is happening, but an attacker node can be adapted to behave like an honest node when another honest node is talking to it.

> For the remaining degradation attacks - someone overwhelming the DHT with misbehaving nodes - there's been a bunch of work in this release looking at how to score peers and figure out which ones aren't worth keeping in the DHT.

Sure, and while this is a good thing, it's ultimately an arms race between the IPFS developers and network attackers who can fool the automated countermeasures. I'm not confident in its long-term ability to fend off attacks on the routing system.

[willscott]

Censorship / availability is the issue. As you lay out, Sybils can be used to target a specific address / piece of content in an attempt to prevent it from being found. The good news is that there are some pretty mechanical things - like maintaining a consensus of known-trusted nodes that can be used to validate a node/piece of content isn't under attack - that should be sufficient until IFPS is quite a bit larger than it is today

I don't think I see the impersonation / bad resolution problem though. IPNS records are content addressed to the key. Having control of a portion of the network isn't sufficient to compromise that (you can prevent availability though).

[jude-]

> The good news is that there are some pretty mechanical things - like maintaining a consensus of known-trusted nodes that can be used to validate a node/piece of content isn't under attack - that should be sufficient until IFPS is quite a bit larger than it is today

What would I be trusting the nodes for? If I'm trusting them to just keep my data available, then why not just put it into S3? What role is IPFS playing at all, then, if I find myself having to pick trusted nodes to defend against low-cost route-censorship attacks?

Also, the size of the network doesn't really seem to make large DHTs resilient to Sybils. BitTorrent in 2010 had over 2 million peers [1], but north of 300,000 of them were Sybils [2]. That's pretty bad.

> I don't think I see the impersonation / bad resolution problem though. IPNS records are content addressed to the key. Having control of a portion of the network isn't sufficient to compromise that (you can prevent availability though).

Correct me if I'm wrong, but IPNS resolves a human-readable name to a content hash, right? If all I'm going off of is the name and the DHT (no DNS), then having a network that can return two (or more!) different content addresses for that name can lead to problems for users, no? If IPNS/IPFS is supposed to be a hypermedia protocol bent on replacing HTTP/DNS, then its inability to handle the case where `google.com` can resolve to either the legitimate Google or a phishing website sounds like a showstopping design flaw that just begging to be abused.

[1] https://www.cs.helsinki.fi/u/jakangas/MLDHT/

[2] https://nymity.ch/sybilhunting/pdf/Wang2012a.pdf

[AgentME]

IPNS names are based on public keys. A sybil attack can't make an IPNS name resolve to an arbitrary attacker-chosen value because the attacker can't make signatures for the public key.

A sybil attack could be used to cause part of the network to see a recent old value for an IPNS name, but clients keeping recent values cached for a while is already something that happens naturally, so it just seems like a more minor example of the general problem that a sybil attack could do a denial-of-service.

[momack2]

Totally agree with you. This is an issue for most open membership p2p networks. Effectively, you need to create some type of reputation system or barrier to accruing power to make it harder for attackers to DOS/manipulate the network than for well-behaving nodes to operate it. IPFS definitely thinks about resistance to a variety of attacks like the ones you describe - but we still have a ways to go. Next steps might look like improvements to the DHT, or other more selective content routing solutions (ex, expanding on our dht-client vs dht-server designation to make content routers more selective/reputation-based).

Check out our most recent research discussion for some thoughts about how we might scale up Sybil resistance in p2p networks: https://www.youtube.com/watch?v=L4SJzoKHKPk

[ChristianBundy]

Alternatively, you can have human-centric P2P networks like Scuttlebutt and Dat where you don't have to worry about sybil attacks. It's a trade-off, because these networks are invite-only, but once you're in you're good to go.