ICMP code/type firewall filters #759
Open
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
FelixMcFelix
force-pushed
the
icmp-code-type-fw
branch
from
a2e5800 to
1e5c952
Compare
FelixMcFelix
changed the title
FelixMcFelix
force-pushed
the
icmp-code-type-fw
branch
from
634792a to
a584a29
Compare
This is encoded using the same `Match` type as before, which captures ranges a bit more succintly. Also applies the same range matches to normal ports, which should greatly simplify huge ranges added in the control plane...
One of the side effects of wanting to filter on ICMP type is that flow IDs need to match that level of specificity. With the old FlowId design, we get *ICMP* and that's it, with the inner ID of an echo paylad added in occasionally. This can lead to fun cases like an allowed ICMP DU opening the door for *all* ICMP packets from that remote host. What we're doing now is providing access to the same two `u16`s in different contexts via `l4_info`/`_mut`, which lets us store the type/code in the source port field (cast as two `u8`s). This does need us to formalise some things we'd taken for granted, e.g., the `mirror` flow for an ICMP echo/request reply needs to also change out the expected type.
FelixMcFelix
force-pushed
the
icmp-code-type-fw
branch
from
634792a to
935fe16
Compare
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.
This PR changes how Oxide VPC firewall protocol matches are specified, such that we can now filter on (ranges of) ICMP types/codes. This allows Nexus and instances to allow limited inbound ICMP traffic where needed to enable correct operation of Path MTU discovery.
One of the main pieces which needed to be accounted for here was the shape of an
InnerFlowIdwhen handling ICMP traffic. Before, both thesource_portanddestination_portwould be used to pull double-duty as storage for ICMP echo IDs. Having this information in the flowkey in some form is necessary to enable outboundpingin a SNAT context. This works great in a world where we treat all ICMP homogenously. However, this would enable situations where we create an pathway for all subsequent ICMP flavours from the remote host.InnerFlowIdnow contains a[u16; 2]which is reinterpreted based on the protocol. For TCP/UDP, these are just the ports as before. In ICMP, we have the type/code/echo_id.mirrored flow IDs now behave a bit more carefully in this regard. ICMP(v6) echo request/reply change the expectedtypevalue at this step and keep the sameecho_idin place.While I've been in this code, I've taken the opportunity to summarise port matches for more typical firewall rules, since that was an
O(n_values)operation in the slowpath.Closes #730.
Closes #468.