Allow server-side to enforce rate-limits to avoid possible DoS and protect iperf Daemon

[Fludizz]

Enhancement Request

I would like to see the option to enforce rate-limits on iperf running in Server/Daemon mode. Specifically when using the UDP testing features. Something similar has already been request in #615 as well.

• Current behavior
  For UDP testing, only the iperf client can set the bandwidth on this and the server "trusts" the client. However, a misconfigured/misbehaving client (either intentionally or accidentally) can then cause the server to sent UDP packets "as fast as it can". This behaviour can have DoS style effects on networks and as such is not desirable.
  As example, the iperf server is on a 10G interface in a backbone network. A client behind a lower rate (e.g. 1G branch) uplink can trigger the server to flood the 1G connection, affecting all clients behind that same uplink and potentially also causes flapping routing protocols if no QoS is defined. No routing means the return packets from the client to the server are lost and client side control of the server is lost.

• Desired behavior
  What would be great would be to allow the server side to have a configurable maximum rate. Any client requesting higher rate would only get the servers configured max rate. Clients requesting lower rates should still behave as is and get the requested rate. This would allow server-side protection of both the network and the server from misbehaving/malicious iperf users.

[patdemko]

I like the idea of this enhancement request as well.

Although my preferred desired behavior would be for the server to through an error specifying the max client testing rate allowed by the server if the client requested data rate [bandwidth (-b) multiplied by number of streams (-P)] was greater than the value set on the server.

[bmah888]

iperf3 was designed as a part of perfSONAR, which includes some limits and protection. The specific part of perfSONAR that handles this is called pScheduler...it might be worth looking into this.

Having iperf3 implement these limits on its own is a worthy idea, although not a high priority for us at this point. If someone wanted to contribute some code, we'd probably take a serious look at it.

[davidBar-On]

I am willing to try to implement some limit features. Based on the request here and perfSONAR I came up with the following suggested list of features and what I think implementation priority. Before implementing, I want to get opinions about what is worth implementing.

Features that should be implemented:

• Limit total Bandwidth for receiving or sending (reverse): --btotal n[KMG]

  • Default is 0 - no limit
  • If limit is reached, test will fail and will not continue with reduced bandwidth

• Limit total number of receive/send data streams: --streams <number>

  • Default is 0 - no limit
  • If limit is reached, test will fail and will not continue with limited number of streams

Features that may be implemented later:

• Allowed Source IP Addresses: --allow-ip <ip1>/<ip2>/...

  • Default: no limit
  • IPv4 <ip> examples: 192.168.19.5, 192.168.19.0/24
  • IPv6 <ip> examples: 2001:db8::1234, fc00:1bad:cafe::/48

• Allowed Host-name (using reverse DNS): --allow-host <host1>/<host2>/...

  • Default: no limit
  • <host> example: example.org

Features not needed:

• Allow only specific users IDs / Name
• Blocking by Source IP Address or by Host Name

[bmah888]

Thanks...we're thinking about which of these options would be useful for ESnet and perfSONAR use cases.

[bmah888]

#615 is related to this issue.

[bmah888]

I'm contemplating some of the other suggested functionality. I think the bitrate limit (#999) will be the most useful. I haven't made up my mind about the number of streams. On the two access control limits, my first reaction is that these duplicate the functionality of host-based firewalls and probably aren't needed (but...one counterpoint is that setting limits in iperf3 does not require any particular privilege, whereas making changes to host-based firewalls usually needs superuser access).

@arlake228 Any thoughts?