integrate authentication

[dshulyak]

dependencies: #2417 #2458 #2538

test plan

• performance evaluation

auth overhead is 32 bytes per datagram and 200ns per encrypt/decrypt operation.
the expected latency degradation should be ~2%.

• longevity testing with disruption (using chaos-mesh)

the goal is to verify that protocol doesn't enter broken state and can recover after
expected disruptions (one sided restarts/crashes, prolonged connectivity loss, packet loss)

i will use the same same workload as in the previous test and automate those disruptions with https://github.com/chaos-mesh/chaos-mesh

running this setup https://github.com/dshulyak/monad-testing/ , everything as expected so far

• worst case dos attacks on authentication protocol

• handshake spamming should hit rate limits and not cause raptorcast thread starvation

• smallest (32bytes) unauthenticated messages with sub-1Gbps rate should not be able to cause raptorcast thread starvation

• upgrades sanity testing on stressnet

it is possible to run auth/non-auth nodes at the same time, and should not cause any disruptions to normal operations.

performance evaluation

i am using latency.rs 100 nodes cluster with simulation toolkit on an aws c6a.48xlarge instance with 192vcpus.
for latency simulatation nodes are divided into 10 buckets, with 20ms incremental latency.
workload sends 2MB raptorcast payload every 1s, latency captures time for encoding, decoding and network propagation

Overall Statistics Summary (g1 excluded):
================================================================================
         Config  Count  Mean  Std   P50   p70   P90   P95   P99
  AUTH 2MB 20ms 28,631 261.2 31.8 261.8 279.8 300.2 307.8 326.2
NOAUTH 2MB 20ms 51,033 259.4 31.1 260.9 279.4 299.1 306.2 321.3

p99 is somewhat around 2% and in lower percentiles auth overhead is less noticeable.

dos attacks

i tested handshake spamming at 2000-3000-4000 handshakes per second and after 2000 they don't increase cpu/memory usage. the limits in place are affective, at the peak such spam utilizes 60% and can't starve raptorcast thread.

cpu usage in raptorcast threads peak at ~20% with 60MB of working set size.

with 500mbps and 1000mbps dataplane thread gets completely starved, raptorcast peaks at 60%.