datapath: link-local unicast addresses can be "host" #25298
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
asauber
commented
May 5, 2023
asauber
commented
May 5, 2023
48e2d1c to
8989ab2
Compare
8989ab2 to
c2e3610
Compare
|
/test |
gentoo-root
approved these changes
May 8, 2023
|
/test-1.26-net-next |
This is a fix for a regression in the local addresses logic, introduced in 080857b as part of the implementation for AddressScopeMax. Addresses with the form of link-local unicast addresses began to be filtered out of the local address aggregation, causing them to labeled with the "world" identity for the sake of policy enforcement. Examples of such addresses include: 169.254.10.10 fe80::1234 This caused issues for a variety of users, whose policies allowing "host" traffic would no longer allow traffic to these addresses, forcing the use of workarounds involving CIDR policies, which is not the intended behavior for this type of address. This was a regression as of Cilium 1.12.0-rc2. One reason for this regression was that logic prior to the change looked at the address scope, whereas logic after the change looked at the address bytes, and it was found that many users had assigned addresses of the forms above but with scope global, causing them to again be filtered unconditionally. This patch factors out the local address filtering logic into a function, removes the skip over IsLinkLocalUnicast(), and adds a variety of unit tests for that function. fixes: #25242 fixes: #23910 fixes: #16308 fixes: #20055 Signed-off-by: Andrew Sauber <andrew.sauber@isovalent.com>
c2e3610 to
dac638e
Compare
|
/test |
2 tasks
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.
Background
This is a fix for a regression in the local addresses logic, introduced in 080857b as part of the implementation for AddressScopeMax. Addresses with the form of a link-local unicast address began to be filtered out of the local address aggregation, causing them to labeled with the "world" identity for the sake of policy enforcement. Examples of such addresses include:
169.254.10.10
fe80::1234
This caused issues for a variety of users, whose policies allowing "host" traffic would no longer allow traffic to these addresses, forcing the use of workarounds involving CIDR policies, which is not the intended behavior for this type of address. This was a regression as of Cilium 1.12.0-rc2. One reason for this regression was that logic prior to the change looked at the address scope, whereas logic after the change looked at the address bytes, and it was found that many users had assigned addresses of the forms above but with scope global, causing them to again be filtered out unconditionally.
Implementation
This patch factors out the local address filtering logic into a function, removes the skip over IsLinkLocalUnicast(), and adds a variety of unit tests for that function.
Important Note
This change has no effect on link-local services such as the AWS Metadata service which operates on
169.254.169.254/32because that address is not assigned to any interface of the local host and thus is not enumerated by rnetlink. The address is still labeled with the "world" identity as usual. This has been tested on EKS and kind.Fixes
fixes: #25242
fixes: #23910
fixes: #16308
fixes: #20055