Hello,
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->props.family != family ||
x->id.spi != spi ||
x->id.proto != proto ||
!xfrm_addr_equal(&x->id.daddr, daddr, family))
continue;
if ((mark & x->mark.m) != x->mark.v)
continue;
if (!xfrm_state_hold_rcu(x))
continue;
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
comments:
/*
* 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,
Stephen.
