ipsec: Simplify XFRM IN policies and templates #35831
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8f95e93 to
f6e8490
Compare
3134823 to
f21725c
Compare
For XFRM IN and FWD policies, we have some optional templates. XFRM IN
and FWD policy templates typically act as additional filters on
decrypted packets. Making them optional simply bypasses those filters.
In that case, it therefore makes little sense to define the other
template fields.
This commit implements that change; when a template is optional, we will
null as many of its fields as possible. Optional templates will
therefore look like:
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000 reqid 0 mode tunnel
level use share any
Note that, as can be seen in the xfrm_state_ok() function in the kernel,
setting an SPI and a ReqID of 0 is equivalent to accepting all SPIs and
ReqIDs.
Also note that this change could be an issue for Encrypted Overlay (EO).
Indeed, in EO mode, we rely on the template ReqID of 2 to identify EO
policies when doing cleanups. So with this change we won't be able to
cleanup some EO policies anymore. However, the next commit is
simplifying XFRM policies such that those separate EO policies won't be
needed anymore.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
Our XFRM IN policies currently look as follows (including the change
from the previous commit). The last two are for Encrypted Overlay. The
second and fourth are for proxy traffic.
src 0.0.0.0/0 dst 10.242.1.0/24
dir in priority 0
mark 0xd00/0xf00
tmpl src 10.242.0.95 dst 10.242.1.62
proto esp spi 0x00000000 reqid 1 mode tunnel
src 0.0.0.0/0 dst 10.242.1.0/24
dir in priority 0
mark 0x200/0xf00
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000 reqid 0 mode tunnel
level use
src 172.18.0.2/32 dst 172.18.0.5/32
dir in priority 0
mark 0xd00/0xf00
tmpl src 172.18.0.2 dst 172.18.0.5
proto esp spi 0x00000000 reqid 2 mode tunnel
src 172.18.0.2/32 dst 172.18.0.5/32
dir in priority 0
mark 0x200/0xf00
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000 reqid 0 mode tunnel
level use
This commit changes them into a single IN policy to allow everything
through:
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 0
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0x00000000 reqid 0 mode tunnel
level use
We've always written our XFRM IN policies to try and match every
possible traffic, so this is clearly the easiest way to do that.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
In subnet mode, the XFRM FWD and IN policies don't depend on the subnet CIDRs. We therefore don't need to install them in the loop over CIDRs and can simply install them once. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
f21725c to
3893b4d
Compare
|
/test |
rgo3
approved these changes
Nov 12, 2024
There was a problem hiding this comment.
Overall LGTM, a few general and non-blocking questions wrt the single IN policy:
- According to the XFRM guide a policy is needed to make sure packets are delivered to local processes, and we can combine them into one single policy because after a packet passes the XFRM decode stage delivery to local process is the only thing we care about correct?
- We still recreate the catch-all IN policy for every node in the cluster, because state and policy creation are quite tightly coupled at the moment, correct? If correct, this could be a potential follow-up issue.
Thanks!
Yep, we don't try to filter what the local processes receive. That's the job of Cilium & k8s network policies.
Yep, that's a good point. We have the same issue for the FWD policies, as Louis noted before. We could probably install all of those once in the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first commit simplifies the optional templates used in most XFRM IN and FWD policies. The second commit simplifies the XFRM IN policies into a single policy. The third moves a bit of code around to avoid unnecessary XFRM policy updates. See commits for details.