Netdev List
 help / color / mirror / Atom feed
From: Stephen Suryaputra <ssuryaextr@gmail.com>
To: netdev@vger.kernel.org
Subject: Security association lookup
Date: Fri, 21 Aug 2020 13:34:54 -0400	[thread overview]
Message-ID: <20200821173454.GA19722@ICIPI.localdomain> (raw)

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.

                 reply	other threads:[~2020-08-21 17:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200821173454.GA19722@ICIPI.localdomain \
    --to=ssuryaextr@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox