[strongSwan-dev] patch proposal: ignore acquire

[Emeric POUPON]

Hi Tobias,

It seems the solution you suggested works fine as long as there is no traffic selector narrowing involved.

Example:
On the responder -> 192.168.120.0/24 === 192.168.110.0/24
On the initiator -> 192.168.110.0/25 === 192.168.120.0/25

On the responder
# setkey -DP
192.168.110.0/24[any] 192.168.120.0/24[any] 255
	in discard
	created: Oct  9 11:12:40 2015  lastused: Oct  9 11:12:40 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=112 seq=1 pid=5405
	refcnt=1
192.168.120.0/24[any] 192.168.110.0/24[any] 255
	out discard
	created: Oct  9 11:12:40 2015  lastused: Oct  9 11:12:40 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=111 seq=0 pid=5405
	refcnt=1


After negotiation and effective narrowing:
# setkey -DP
V50XXA4B0000045>showSPD
192.168.110.0/24[any] 192.168.120.0/24[any] 255
	in discard
	created: Oct  9 11:12:40 2015  lastused: Oct  9 11:14:11 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=112 seq=3 pid=5406
	refcnt=1
192.168.110.0/25[any] 192.168.120.0/25[any] 255
	in ipsec
	esp/tunnel/192.168.56.110-192.168.56.120/unique:1
	created: Oct  9 11:14:09 2015  lastused: Oct  9 11:14:09 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=116 seq=2 pid=5406
	refcnt=1
192.168.120.0/24[any] 192.168.110.0/24[any] 255
	out discard
	created: Oct  9 11:12:40 2015  lastused: Oct  9 11:12:40 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=111 seq=1 pid=5406
	refcnt=1
192.168.120.0/25[any] 192.168.110.0/25[any] 255
	out ipsec
	esp/tunnel/192.168.56.120-192.168.56.110/unique:1
	created: Oct  9 11:14:09 2015  lastused: Oct  9 11:14:09 2015
	lifetime: 9223372036854775807(s) validtime: 0(s)
	spid=115 seq=0 pid=5406
	refcnt=1

Packets are successfully received (the SPD is not checked for incoming packets)
But packets are never sent, they seem to be dropped by the kernel (the lastused of the out discard policy is refreshed)


What do you think?

Emeric


----- Mail original -----
De: "Tobias Brunner" <tobias at strongswan.org>
À: "Emeric POUPON" <emeric.poupon at stormshield.eu>
Cc: dev at lists.strongswan.org
Envoyé: Lundi 5 Octobre 2015 18:20:35
Objet: Re: [strongSwan-dev] patch proposal: ignore acquire

Hi Emeric,

> I guess you are not interested by the "ignore_acquire" approach?

Not really.  Drop policies are exactly for this purpose, while trap
policies are to trigger IKE/IPsec SAs, not to drop traffic.  Ignoring
acquires makes not much sense, in particular because the kernel's
behavior is quite different when traffic matches a trap policy.  The
kernel might create a temporary SA and cache packets until the SA is
established, so that could require lots of resources if the other peer
does not establish the connection for a while.  And depending on the OS
settings and the traffic the kernel might send lots of acquires to the
daemon (for instance, on FreeBSD the default is to trigger an acquire
every 10th packet, see net.key.blockacq_count).

> The only drawback is that we have to manually add a "drop" connection for each "responder only" connection.

Using the `also` keyword you could simplify this and avoid having to
duplicate the traffic selector definition (e.g. define left|rightsubnet
in the "drop" connection and include it in the "responder" connection
and override/add settings appropriately).

Regards,
Tobias