undefined | Better HN

0 pointsjude-5y ago0 comments

> 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.

0 comments

willscott5y ago

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-OP5y ago

> 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

AgentME5y ago

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.

j / k navigate · click thread line to collapse