From: Lorenzo Colitti <lorenzo@google.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, subashab@codeaurora.org,
nharold@google.com, davem@davemloft.net
Subject: [PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst pair
Date: Thu, 21 Dec 2017 02:06:00 +0900 [thread overview]
Message-ID: <20171220170607.41516-1-lorenzo@google.com> (raw)
When using IPsec tunnel mode, VTIs provide many benefits compared
to direct configuration of xfrm policies / states. However, one
limitation is that there can only be one VTI between a given pair
of IP addresses. This does not allow configuring multiple IPsec
tunnels to the same security gateway. This is required by some
deployments, for example I-WLAN [3GPP TS 24.327].
This patchset introduces a new VTI_KEYED flag that allows
configuration of multiple VTIs between the same IP address
pairs. The semantics are as follows:
- The output path is the same as current VTI behaviour, where a
routing lookup selects a VTI interface, and the VTI's okey
specifies the mark to use in the XFRM lookup.
- The input and ICMP error paths instead work by first looking up
an SA with a loose match that ignores the mark. That mark is
then used to find the tunnel by ikey (for input packets) or
okey (for ICMP errors).
In order for ICMP errors to work, flags are added to the common
IP lookup functions to ignore the tunnel ikey and to look up
tunnels by okey instead of ikey.
On the same IP address pair, keyed VTIs can coexist with each
other (as long as the ikeys are different), but cannot coexist
with keyless VTIs. This is because the existing keyless VTI
behaviour (which this series does not change) is to always accept
packets matching an input policy, regardless of whether there is
any matching XFRM state. Thus, the keyless VTI would accept the
traffic for the keyed tunnel and drop it because it would not
match the keyed tunnel's state.
Changes from RFC series:
- Processing of ICMP errors now works when ikey != okey.
- Series now contains changes to the common tunnel lookup
functions to match tunnels by okey and to ignore ikey when
matching.
- Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose.
- Made vti6_lookup static as it should have been.
next reply other threads:[~2017-12-20 17:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 17:06 Lorenzo Colitti [this message]
2017-12-20 17:06 ` [PATCH ipsec-next 1/7] net: xfrm: Don't check for TUNNEL_KEY when hashing VTI tunnels Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 2/7] net: ipv4: Add new flags to tunnel lookup Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 3/7] net: xfrm: Add an xfrm lookup that ignores the mark Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 4/7] net: xfrm: Find VTI interfaces from xfrm_input Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 5/7] net: xfrm: Deliver packets to keyed VTI tunnels Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 6/7] net: xfrm: Allow userspace to configure " Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 7/7] net: xfrm: Don't pass tunnel objects to xfrm6_rcv_spi Lorenzo Colitti
2018-01-03 12:10 ` [PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst pair Steffen Klassert
2018-01-04 16:41 ` Lorenzo Colitti
2018-01-05 7:16 ` Steffen Klassert
2018-01-05 14:32 ` [ipsec-next,0/7] : " Antony Antony
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=20171220170607.41516-1-lorenzo@google.com \
--to=lorenzo@google.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nharold@google.com \
--cc=steffen.klassert@secunet.com \
--cc=subashab@codeaurora.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;
as well as URLs for NNTP newsgroup(s).