pfdhcplistener rate-limiting

[dwlfrth]

pfdhcplistener is currently "vulnerable" to "mass-trafic" attacks (it is actually more pfqueue but POE is pfdhcplistener). The daemon will receive DHCP packets then forwards them to the appropriate queue which may create a big processing queue in the case a device is sending a lot of DHCP discover / request.

pfdhcplistener should be able to "rate-limit" itself based on number of request from a same device per X time.

[dwlfrth]

@julsemaan proposed to use redis to store the "count" of packets coming from different devices based on mac-prefixed redis entries and scan over them to determine whether or not we should rate-limit (send to pfqueue or "discard")

[louismunro]

I propose we move the iplog to redis.

[jrouzierinverse]

Would it be simpler to keep that logic within the pfdhcplistener to avoid involving redis.

[julsemaan]

@jrouzierinverse that would work with an in-memory map but we wouldn't have the auto-expire of Redis and would need to write our own logic to calculate the throttling.

Both would be good, just an implementation detail I guess

[jrouzierinverse]

You just use CHI for the auto expire login

[jrouzierinverse]

Using redis directly could also be an option.
What I did not understand is the part about "scan over them to determine whether or not we should rate-limit"

I would prefer to avoid scanning things in redis.