Re: [PATCH net-next 2/2] ipvs: drop conn templates under attack

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCH net-next 2/2] ipvs: drop conn templates under attack
Cc: lvs-devel@xxxxxxxxxxxxxxx, mkoutny@xxxxxxxx, mkubecek@xxxxxxxx
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Mon, 4 Jun 2018 04:08:32 -0400
On Sat, Jun 02, 2018 at 09:50:02PM +0300, Julian Anastasov wrote:
> Before now, connection templates were ignored by the random
> dropentry procedure. But Michal Koutný suggests that we
> should add exception for connections under SYN attack.
> He provided patch that implements it for TCP:
> <quote>
> IPVS includes protection against filling the ip_vs_conn_tab by
> dropping 1/32 of feasible entries every second. The template
> entries (for persistent services) are never directly deleted by
> this mechanism but when a picked TCP connection entry is being
> dropped (1), the respective template entry is dropped too (realized
> by expiring 60 seconds after the connection entry being dropped).
> There is another mechanism that removes connection entries when they
> time out (2), in this case the associated template entry is not deleted.
> Under SYN flood template entries would accumulate (due to their entry
> longer timeout).
> The accumulation takes place also with drop_entry being enabled. Roughly
> 15% ((31/32)^60) of SYN_RECV connections survive the dropping mechanism
> (1) and are removed by the timeout mechanism (2)(defaults to 60 seconds
> for SYN_RECV), thus template entries would still accumulate.
> The patch ensures that when a connection entry times out, we also remove
> the template entry from the table. To prevent breaking persistent
> services (since the connection may time out in already established state)
> we add a new entry flag to protect templates what spawned at least one
> established TCP connection.
> </quote>
> We already added ASSURED flag for the templates in previous patch, so
> that we can use it now to decide which connection templates should be
> dropped under attack. But we also have some cases that need special
> handling.
> We modify the dropentry procedure as follows:
> - Linux timers currently use LIFO ordering but we can not rely on
> this to drop controlling connections. So, set cp->timeout to 0
> to indicate that connection was dropped and that on expiration we
> should try to drop our controlling connections. As result, we can
> now avoid the ip_vs_conn_expire_now call.
> - move the cp->n_control check above, so that it avoids restarting
> the timer for controlling connections when not needed.
> - drop unassured connection templates here if they are not referred
> by any connections.
> On connection expiration: if connection was dropped (cp->timeout=0)
> try to drop our controlling connection except if it is a template
> in assured state.
> In ip_vs_conn_flush change order of ip_vs_conn_expire_now calls
> according to the LIFO timer expiration order. It should work
> faster for controlling connections with single controlled one.
> Suggested-by: Michal Koutný <mkoutny@xxxxxxxx>
> Signed-off-by: Julian Anastasov <ja@xxxxxx>

Acked-by: Simon Horman <horms+renesas@xxxxxxxxxxxx>
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>