ECMP and DDoS Client Authentication

 

When deploying DDoS Mitigation, it is normal to enable certain kinds of client authentication method to determine a client is valid or not. For example, DDoS mitigator might use TCP authentication to prevent a SYN Flood attack:

The first TCP connection from a client will never reach the intended server.

The DDoS mitiigator will check the 3 way handshake behaving as the target server by responding a SYN ACK. Assuming only valid client will then proceed to response a ACK thus to finish the handshake, only then this client is considered a valid client. While mitigator will still RST the connection and forward all subsequent connections from the same client.

If a client could not finish 3 way handshake (no ACK is received), mitigator could either try keep authenticating or put this client IP in a blacklist to drop all connections.

But, when deploying multiple DDoS mitigators using ECMP, extra considerations are needed for any type of client authentications.

For example, 3 DDoS mitigator devices running ECMP with the outside router here, based on the ECMP algorithm, traffic from the same client (same source IP) might reach any of these 3 devices. 

Even for TCP Authentications mentioned above, there should be a sync mechanism among these 3 devices to sync authenticated or blacklisted entries. Otherwise, users might experience multiple times of authentications and experience noticeable delay when reaching the target server.

TCP Authentication actually is a simple case as some it only involves one connection.

Some other authentication method,  such as DNS Authentication by forcing client using TCP and HTTP Authentication using HTTP cookie, will require multiple connections to achieve the goal. These will get more complex as different connections might reach different DDoS mitigators, extra design/syn/testing must be considered for these cases.