cryptonote_protocol: some stricter checks on object requests

[moneromooo-monero]

No description provided.

[xiphon]

Think we shouldn't forbid non contiguous get blocks requests.

It is just the way Monero reference implementation (monreod) currently works and I doubt we should enforce this on the protocol level.

Could you clarify the problem/weakness here?

[moneromooo-monero]

It prevents the (admittedly fairly coarse) check against pre-v4 and post v4 max blocks from being useful.

[xiphon]

This doesn't help to mitigates a DoS anyhow. Am i missing something?

[moneromooo-monero]

If blocks aren't contiguous, you can't easily clamp to 20 (instead of 100) for post rct.

[moneromooo-monero]

and if you're going to say "count bytes", it's not a trivial patch.

[xiphon]

NOTIFY_REQUEST_GET_OBJECTS request contains a list of block hashes to receive. It puts no restriction on the heights.
So it allows me to request block #0 and block #100 in a single request.

You are going to forbid this and force p2p client to always request contiguous blocks, i.e. block #0, block #1, block #2.

What is the point of having a list of block hashes in the request then? Just a the first block hash and blocks count would be enough.

Summing this up. The patch introduces some problems to legit P2P clients and changes almost nothing from the DoS perspective, an attacker will just select 100 contiguous blocks span and spam your node with the requests.

[xiphon]

The proper way would be just to change the server code. We should just limit blocks count we send back in the reply. I.e. no matter how many blocks a client requested, we always serve only first N blocks from the request, N - the limit we want to put there (20/100/500/etc.).

[moneromooo-monero]

monerod does not do that (unless you find a case where it does).
The point of having a list of block hashes is that it is a lot more work to avoid doing that. WhatI don't like the argument of saying no improvement because a better improvement can be made regardless of the amount of work involved (in general, it can apply in some cases). There wlil be a new call where you give a starting hash and a number, but I object to having to do everything at once or nothing.
The patch does not introduce problems to legit P2P clients, unless you find a case where it does.
The patch does mitigate DoS potential somewhat (I do not claim it removes the DoS) because it does not allow more than 20 blocks for the borromean part of the chain where blocks are large, and no more than 100 (which is the max monerod requests unless you change it manually) otherwise, rather than 500.

[xiphon]

It is all about P2P protocol, not about referene monero node implementation (monerod).

There might be other monero node implementations. And this change will break the P2P protocol for them. Even if you still want to do this, you should bump the P2P protocol version.

But i already mentioned the correct way this should be handled, see #6554 (comment)

[moneromooo-monero]

I really do not care. If anyone made custom code, they can just change the number of blocks they have.
You can't just send fewer blocks, the client will complain and drop. This will require something else, which I will later.

[xiphon]

I bet 500 blocks limit works pretty well. Any good reason to change this?

[moneromooo-monero]

To mitigate DoS potential, as above. 100 objects are smaller than 500 (ceteris paribus).

[xiphon]

The first two commits looks okay to me.

• cryptonote_protocol: reject requests/notifications before handshake fed0ced
• cryptonote_protocol: stricter limit to number of objects requested fb24d22

Regarding the third commit: i'd better nuke it. Or drop switching between pre-v4 limit and post-v4 limit, i.e. use single limit (no more than 100 blocks per request).

[moneromooo-monero]

Nuke because it's actually wrong, or because you don't like it because there's a better way to do it later if we spend more time on it ?

[moneromooo-monero]

(I don't see "it will break third party code that happens to request more blocks than monerod" as wrong, it's what we want to prevent in the first place)

[moneromooo-monero]

I've removed the third one then, since rbrunner is also against.

[moneromooo-monero]

I got actual blockchain data:

max block size pre v4: 89417
max block size post v4: 474152

Assuming dupes can be requested (I think they can, I did not double check):
Without the third patch, you can request 474152 * 100 = 45 MB
With the limit to 20 post v4, you can request 474152 * 20 = 9 MB
With the restriction to sequential, you can request ~ 40 MB
With both, you can request ~ 8 MB

So the sequential restrictions gains a bit, while the limit to 20 gains a lot.

[moneromooo-monero]

(up to height 2e6, I do not expect the numbers to differ substantially for the tail end)

[xnbya]

The limit to 20 blocks post v4 is important for mitigating the DOS. It doesn't break anything for existing monerod clients, and it should be simple for any other implementations to reduce the number of blocks they request. The blocks being sequential is not as important, but again it does not break any known non-spammy implementations.