Body downloader response filtering

[rkrasiuk]

Malicious peers might respond with a single valid block body. Since receiving fewer block bodies than requested is acceptable, we had to implement a check to disregard such responses.

https://github.com/paradigmxyz/reth/blob/f771e23f9a3e4238bb413a55f02d1536126a0ea1/crates/net/downloaders/src/bodies/request.rs#L120-L126

This was a critical issue because the body validation used to happen only after all responses had been collected. The immediate response validation (#1080) mitigated this issue by validating each response upon arrival.

There is still one potential "attack" vector left that would impact the sync speed. Consider the scenario where a malicious peer responds with a single valid block for 200 requested even tho the potential response size for all 200 blocks (or a subset) is within the acceptable limits (see geth's soft response limit and maximum body count).

The current method only discards responses with a single body if more than one were requested. It can be bypassed by sending 2 or 3 bodies and still negatively impact the sync speed.

@mattsse thoughts?

[mattsse]

peer responds with a single valid block for 200 requested

retries are not guaranteed to go to the same peer.

So I think we should just penalize a peer that sends fewer blocks?

[rkrasiuk]

@mattsse the problem is we don't know the expected response size beforehand. for all we know these could be blocks with one tx only or massive blocks with hundreds of transactions

[gakonst]

When is this really an issue?

If during long syncing I peer with somebody that intentionally tries to feed me less blocks than I requested, but not 1? Are Geth/Erigon also vulnerable to this (I did not get how the soft limit helps with receiving less data tahn requested)

Is it an issue if I'm already synced and downloading 1 block at a time?

[mattsse]

@rkrasiuk is this still relevant or can we close?

[rkrasiuk]

@mattsse this is still relevant, but not a priority

[github-actions[bot]]

This issue is stale because it has been open for 21 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.