[PATCH v2 0/3] Send RST for guest packets with no flow
As we discussed on email, this adds support for sending an RST in response to packets from the guest which don't match an existing flow and are neither SYN (requesting a new connection) nor themselves RST. This is a sligjhtly larger patch than I'd like, but I can't really see a way to simplify it without making fairly extensive reworks to share more code with paths for RST where there is a known connection. That would end up being more churn. This doesn't (IMO) correctly handle IPv6 flow labels. Fixing that raises several additional issues regarding flow labels, so I've decided to defer that for now. v2: * Assorted cosmetic fixups * Use correct IPv6 flow label for packets * This required two preliminary patches * tcp_rst_no_conn() is now static David Gibson (3): ip: Helpers to access IPv6 flow label tap: Consider IPv6 flow label when building packet sequences tcp: Send RST in response to guest packets that match no connection ip.h | 24 ++++++++++++++++++ tap.c | 25 ++++++++++--------- tap.h | 6 +++++ tcp.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- tcp.h | 2 +- 5 files changed, 118 insertions(+), 17 deletions(-) -- 2.48.1
The flow label is a 20-bit field in the IPv6 header. The length and
alignment make it awkward to pass around as is. Obviously, it can be
packed into a 32-bit integer though, and we do this in two places. We
have some further upcoming places where we want to manipulate the flow
label, so make some helpers for marshalling and unmarshalling it to an
integer.
Signed-off-by: David Gibson
To allow more batching, we group together related packets into "seqs" in
the tap layer, before passing them to the L4 protocol layers. Currently
we consider the IP protocol, both IP addresses and also the L4 ports when
grouping things into seqs. We ignore the IPv6 flow label.
We have some future cases where we want to consider the the flow label in
the L4 code, which is awkward if we could be given a single batch with
multiple labels. Add the flow label to tap6_l4_t and group by it as well
as the other criteria. In future we could possibly use the flow label
_instead_ of peeking into the L4 header for the ports, but we don't do so
for now.
The guest should use the same flow label for all packets in a low, but if
it doesn't this change won't break anything, it just means we'll batch
things a bit sub-optimally.
Signed-off-by: David Gibson
Currently, if a non-SYN TCP packet arrives which doesn't match any existing
connection, we simply ignore it. However RFC 9293, section 3.10.7.1 says
we should respond with an RST to a non-SYN, non-RST packet that's for a
CLOSED (i.e. non-existent) connection.
This can arise in practice with migration, in cases where some error means
we have to discard a connection. We destroy the connection with tcp_rst()
in that case, but because the guest is stopped, we may not be able to
deliver the RST packet on the tap interface immediately. This change
ensures an RST will be sent if the guest tries to use the connection again.
A similar situation can arise if a passt/pasta instance is killed or
crashes, but is then replaced with another attached to the same guest.
This can leave the guest with stale connections that the new passt instance
isn't aware of. It's better to send an RST so the guest knows quickly
these are broken, rather than letting them linger until they time out.
Signed-off-by: David Gibson
On Wed, 5 Mar 2025 15:32:27 +1100
David Gibson
As we discussed on email, this adds support for sending an RST in response to packets from the guest which don't match an existing flow and are neither SYN (requesting a new connection) nor themselves RST.
This is a sligjhtly larger patch than I'd like, but I can't really see a way to simplify it without making fairly extensive reworks to share more code with paths for RST where there is a known connection.
Yeah, me neither...
That would end up being more churn.
This doesn't (IMO) correctly handle IPv6 flow labels. Fixing that raises several additional issues regarding flow labels, so I've decided to defer that for now.
v2: * Assorted cosmetic fixups * Use correct IPv6 flow label for packets * This required two preliminary patches * tcp_rst_no_conn() is now static
Applied. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio