Limit the number of simultaneous inbound TCP connections

[tomaka]

(I somehow misremember having done that in the past, but apparently not)

At the moment, if too many TCP connections arrive, we will reach the system's ulimit, which also has the consequence that we can't open outbound TCP connections anymore, and not open files anymore.

It seems preferable to limit the number of TCP connections manually rather than relying on the ulimit.

[burdges]

I forget which Noise handshakes protocol labs likes, but around whitelisting..

Anything with a K in the second position authenticates the receiver in the first packet, and then I in the first position authenticates the sender in the first, but only to the desired receiver. So IK, IKpsk1, etc. all permit some whitelisting by receivers. At least this holds with UDP ala nQUIC but not sure about TCP.

It's unclear why the psk comes after the s in IKpsk1, maybe because its identified by the s, but identifying it another way sounds smarter, and then protects the s. Add some IKpsk0 then maybe?

I think TLS 1.3 cannot do any whitelisting without its 0-RTT extension https://moderncrypto.org/mail-archive/noise/2015/000125.html I'd think 0-RTT TLS 1.3 hides initiators identities like IKpsk0, so better than IK and IKpsk1.

Appears https://github.com/rot256/ninn was last worked on two years ago, not sure if a more recent nQUIC fork exists. I'll ask around about nQUIC being reviewed, but so far all I found is https://moderncrypto.org/mail-archive/noise/2018/001929.html https://moderncrypto.org/mail-archive/noise/2018/001938.html https://moderncrypto.org/mail-archive/noise/2018/001939.html https://moderncrypto.org/mail-archive/noise/2018/001951.html

[burdges]

It appears the nQUIC authors wrote the ninn fork of quinn https://eprint.iacr.org/2019/028.pdf so maybe we should bring ninn up to date with quinn.

In any case, we could prioritize validator-validator connections whenever you like next year. We should delay using too much prioritization or whitelists for validator-collator or other connections though because it might bring compleixty.. well like sentry nodes did.

[burdges]

I'll also caution that IK permits a replay attacks on the first round, so adversaries might DoS you by pretending to be other validators. There are handshakes like IKpsk1, and this hypothetical IKpsk0, that avoid this issue by ratcheting the psk with every successful connection.

Is this one packet DoS mode really correct? Or can an adversary DoS with much less? Or do they want more?

[tomaka]

libp2p/rust-libp2p#1839

[tomaka]

Was done in #7606.
We have a limit of 10000 total connections.