Netdev Archive on
help / color / mirror / Atom feed
* Security association lookup
@ 2020-08-21 17:34 Stephen Suryaputra
  0 siblings, 0 replies; only message in thread
From: Stephen Suryaputra @ 2020-08-21 17:34 UTC (permalink / raw)
  To: netdev


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,


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-08-21 17:35 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-21 17:34 Security association lookup Stephen Suryaputra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).