From: Steffen Klassert <steffen.klassert@secunet.com>
To: David Miller <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Steffen Klassert <steffen.klassert@secunet.com>,
<netdev@vger.kernel.org>
Subject: pull request (net-next): ipsec-next 2018-07-27
Date: Fri, 27 Jul 2018 09:24:35 +0200 [thread overview]
Message-ID: <20180727072449.11896-1-steffen.klassert@secunet.com> (raw)
1) Extend the output_mark to also support the input direction
and masking the mark values before applying to the skb.
2) Add a new lookup key for the upcomming xfrm interfaces.
3) Extend the xfrm lookups to match xfrm interface IDs.
4) Add virtual xfrm interfaces. The purpose of these interfaces
is to overcome the design limitations that the existing
VTI devices have.
The main limitations that we see with the current VTI are the
following:
VTI interfaces are L3 tunnels with configurable endpoints.
For xfrm, the tunnel endpoint are already determined by the SA.
So the VTI tunnel endpoints must be either the same as on the
SA or wildcards. In case VTI tunnel endpoints are same as on
the SA, we get a one to one correlation between the SA and
the tunnel. So each SA needs its own tunnel interface.
On the other hand, we can have only one VTI tunnel with
wildcard src/dst tunnel endpoints in the system because the
lookup is based on the tunnel endpoints. The existing tunnel
lookup won't work with multiple tunnels with wildcard
tunnel endpoints. Some usecases require more than on
VTI tunnel of this type, for example if somebody has multiple
namespaces and every namespace requires such a VTI.
VTI needs separate interfaces for IPv4 and IPv6 tunnels.
So when routing to a VTI, we have to know to which address
family this traffic class is going to be encapsulated.
This is a lmitation because it makes routing more complex
and it is not always possible to know what happens behind the
VTI, e.g. when the VTI is move to some namespace.
VTI works just with tunnel mode SAs. We need generic interfaces
that ensures transfomation, regardless of the xfrm mode and
the encapsulated address family.
VTI is configured with a combination GRE keys and xfrm marks.
With this we have to deal with some extra cases in the generic
tunnel lookup because the GRE keys on the VTI are actually
not GRE keys, the GRE keys were just reused for something else.
All extensions to the VTI interfaces would require to add
even more complexity to the generic tunnel lookup.
So to overcome this, we developed xfrm interfaces with the
following design goal:
It should be possible to tunnel IPv4 and IPv6 through the same
interface.
No limitation on xfrm mode (tunnel, transport and beet).
Should be a generic virtual interface that ensures IPsec
transformation, no need to know what happens behind the
interface.
Interfaces should be configured with a new key that must match a
new policy/SA lookup key.
The lookup logic should stay in the xfrm codebase, no need to
change or extend generic routing and tunnel lookups.
Should be possible to use IPsec hardware offloads of the underlying
interface.
5) Remove xfrm pcpu policy cache. This was added after the flowcache
removal, but it turned out to make things even worse.
From Florian Westphal.
6) Allow to update the set mark on SA updates.
From Nathan Harold.
7) Convert some timestamps to time64_t.
From Arnd Bergmann.
8) Don't check the offload_handle in xfrm code,
it is an opaque data cookie for the driver.
From Shannon Nelson.
9) Remove xfrmi interface ID from flowi. After this pach
no generic code is touched anymore to do xfrm interface
lookups. From Benedict Wong.
10) Allow to update the xfrm interface ID on SA updates.
From Nathan Harold.
11) Don't pass zero to ERR_PTR() in xfrm_resolve_and_create_bundle.
From YueHaibing.
12) Return more detailed errors on xfrm interface creation.
From Benedict Wong.
13) Use PTR_ERR_OR_ZERO instead of IS_ERR + PTR_ERR.
From the kbuild test robot.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit dd55c4ea9e6ba957083f985f33f994c23b405e9e:
Merge branch 'r8169-enable-ASPM-on-RTL8168E-VL' (2018-06-23 20:54:56 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
for you to fetch changes up to c6f5e017df9dfa9f6cbe70da008e7d716d726f1b:
xfrm: fix ptr_ret.cocci warnings (2018-07-27 06:47:28 +0200)
----------------------------------------------------------------
Arnd Bergmann (2):
xfrm: use time64_t for in-kernel timestamps
ipv6: xfrm: use 64-bit timestamps
Benedict Wong (2):
xfrm: Remove xfrmi interface ID from flowi
xfrm: Return detailed errors from xfrmi_newlink
Florian Westphal (1):
xfrm: policy: remove pcpu policy cache
Nathan Harold (2):
xfrm: Allow Set Mark to be Updated Using UPDSA
xfrm: Allow xfrmi if_id to be updated by UPDSA
Shannon Nelson (1):
xfrm: don't check offload_handle for nonzero
Steffen Klassert (4):
xfrm: Extend the output_mark to support input direction and masking.
flow: Extend flow informations with xfrm interface id.
xfrm: Add a new lookup key to match xfrm interfaces.
xfrm: Add virtual xfrm interfaces
YueHaibing (1):
xfrm: fix 'passing zero to ERR_PTR()' warning
kbuild test robot (1):
xfrm: fix ptr_ret.cocci warnings
include/net/dst.h | 14 +
include/net/xfrm.h | 59 ++-
include/uapi/linux/if_link.h | 10 +
include/uapi/linux/xfrm.h | 5 +-
net/core/pktgen.c | 2 +-
net/ipv4/esp4_offload.c | 6 +-
net/ipv6/esp6_offload.c | 6 +-
net/ipv6/xfrm6_mode_ro.c | 2 +-
net/key/af_key.c | 6 +-
net/xfrm/Kconfig | 8 +
net/xfrm/Makefile | 1 +
net/xfrm/xfrm_device.c | 19 +-
net/xfrm/xfrm_input.c | 5 +
net/xfrm/xfrm_interface.c | 975 +++++++++++++++++++++++++++++++++++++++++++
net/xfrm/xfrm_output.c | 3 +-
net/xfrm/xfrm_policy.c | 314 ++++++--------
net/xfrm/xfrm_state.c | 48 ++-
net/xfrm/xfrm_user.c | 94 ++++-
18 files changed, 1331 insertions(+), 246 deletions(-)
create mode 100644 net/xfrm/xfrm_interface.c
next reply other threads:[~2018-07-27 8:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 7:24 Steffen Klassert [this message]
2018-07-27 7:24 ` [PATCH 01/14] xfrm: Extend the output_mark to support input direction and masking Steffen Klassert
2018-07-27 7:24 ` [PATCH 02/14] flow: Extend flow informations with xfrm interface id Steffen Klassert
2018-07-27 7:24 ` [PATCH 03/14] xfrm: Add a new lookup key to match xfrm interfaces Steffen Klassert
2018-07-27 7:24 ` [PATCH 04/14] xfrm: Add virtual " Steffen Klassert
2018-07-27 7:24 ` [PATCH 05/14] xfrm: policy: remove pcpu policy cache Steffen Klassert
2018-07-27 7:24 ` [PATCH 06/14] xfrm: Allow Set Mark to be Updated Using UPDSA Steffen Klassert
2018-07-27 7:24 ` [PATCH 07/14] xfrm: use time64_t for in-kernel timestamps Steffen Klassert
2018-07-27 7:24 ` [PATCH 08/14] ipv6: xfrm: use 64-bit timestamps Steffen Klassert
2018-07-27 7:24 ` [PATCH 09/14] xfrm: don't check offload_handle for nonzero Steffen Klassert
2018-07-27 7:24 ` [PATCH 10/14] xfrm: Remove xfrmi interface ID from flowi Steffen Klassert
2018-07-27 7:24 ` [PATCH 11/14] xfrm: Allow xfrmi if_id to be updated by UPDSA Steffen Klassert
2018-07-27 7:24 ` [PATCH 12/14] xfrm: fix 'passing zero to ERR_PTR()' warning Steffen Klassert
2018-07-27 7:24 ` [PATCH 13/14] xfrm: Return detailed errors from xfrmi_newlink Steffen Klassert
2018-07-27 7:24 ` [PATCH 14/14] xfrm: fix ptr_ret.cocci warnings Steffen Klassert
2018-07-27 16:37 ` pull request (net-next): ipsec-next 2018-07-27 David Miller
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=20180727072449.11896-1-steffen.klassert@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--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