lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Fri, 21 Aug 2020 13:34:54 -0400
From:   Stephen Suryaputra <>
Subject: Security association lookup


Reading the RFC 4301, it seems that security association search can hit
based on the SPI alone. But, __xfrm_state_lookup() matches the dest IP
address as well:

static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
					      const xfrm_address_t *daddr,
					      __be32 spi, u8 proto,
					      unsigned short family)
	unsigned int h = xfrm_spi_hash(net, daddr, spi, proto, family);
	struct xfrm_state *x;

	hlist_for_each_entry_rcu(x, net->xfrm.state_byspi + h, byspi) {
		if (x-> != family ||
		    x->id.spi       != spi ||
		    x->id.proto     != proto ||
		    !xfrm_addr_equal(&x->id.daddr, daddr, family))

		if ((mark & x->mark.m) != x->mark.v)
		if (!xfrm_state_hold_rcu(x))
		return x;

	return NULL;

The context is manual keying using iproute2 and the policy and state are
configured with dst <ip_addr>/<prefix>. Not having dealt with ipsec before,
at both code and system level, what am I missing? Do I understand the
standard and the iproute2 tool correctly?

If this, looking up based on spi alone and potentially prefixed addresses as
being stored in the selector, is allowed per specifications; is there a
work being done?

Above is a sample point on receive. Transmit seems to work the same too
except an xfrm_state is allocated and key mgr is notified. For manual
keying, is there a key mgr?

I read BSD code which seems to be doing the same with the following

 * allocating a usable SA entry for a *INBOUND* packet.
 * Must call key_freesav() later.
 * OUT: positive:	pointer to a usable sav (i.e. MATURE or DYING state).
 *	NULL:		not found, or error occurred.
 * According to RFC 2401 SA is uniquely identified by a triple SPI,
 * destination address, and security protocol. But according to RFC 4301,
 * SPI by itself suffices to specify an SA.
 * Note that, however, we do need to keep source address in IPsec SA.
 * IKE specification and PF_KEY specification do assume that we
 * keep source address in IPsec SA.  We see a tricky situation here.

Thank you,


Powered by blists - more mailing lists