Why does Qubes firewall separate IPv4 and IPv6?

[qubist]

Hi,

Why does Qubes OS explicitly handle IPv4 and IPv6 through two separate nft tables (ip qubes and ip6 qubes), resulting in duplication of rules in these two tables?

[Eric W. Biederman]

qubist <qubist...@riseup.net> writes:

> Hi,
>
> Why does Qubes OS explicitly handle IPv4 and IPv6 through two separate nft tables (ip qubes and ip6 qubes), resulting in duplication of rules in these two tables?

I looked at something a while ago and at the time everything was based
on iptables. To the point that nft table support was simply created by
something emulating iptables.

So I expect this is just historical where the code has not truly moved
beyond iptables.

Eric

[unman]

[quote]

So I expect this is just historical where the code has not truly moved
beyond iptables.

[/quote]
I'm sure this is part of it.
However, the 4 and 6 rulesets are distinct and although they could be
merged to a single table, the result would not be any cleaner. While
there is some duplication, there are also distinctions.
Sometimes keeping separate tables allows for greater clarity.

--
I never presume to speak for the Qubes team.
When I comment in the mailing lists I speak for myself.

[qubist]

On Sat, 23 Mar 2024 13:05:39 +0000 'unman' via qubes-devel wrote:

> However, the 4 and 6 rulesets are distinct and although they could be
> merged to a single table, the result would not be any cleaner. While
> there is some duplication, there are also distinctions.
> Sometimes keeping separate tables allows for greater clarity.

I am not quite sure what you mean by cleaner and greater clarity.
Compare the 2 files I am attaching.

separate.nft - as it is currently in Qubes
single.nft - a quick attempt to merge them into a single inet table

separate - 133 lines
single - 82 lines

I have not made any performance comparison but in regards to
simplicity, single.nft looks simpler to me. Perhaps it can be optimized
even more, e.g. dropping invalid packets in early in prerouting hook
instead of letting them to input.

What do you think? Has any optimization been considered?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

A single table is surely shorter, but TBH I'm not sure if it's clearer.
Some rules needs to be duplicated for v4 and v6, some don't. IMO the main
advantage of the single table approach is purely port-based rules (UDP
or TCP), but the default firewall doesn't have many of them. They may be
relevant for custom-input chain (but not always - sometimes you might
want to use IP address in those too), and rarely for custom-forward.

In any case, changing it now is not an option. It would mean changing
the API for custom rules, which was a huge pain for users migrating to
R4.2, and we are not going to do that _again_ now.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBY80ACgkQ24/THMrX
1yzebgf/dkFXbsl7FYfgeqPEJTZ/HMPWieXum7vI06FpuLlHncPMhbJ833prtAvK
CIZF/iEEOsngyiGT0VaH45NO3H4QBDftikwDQ3eB91+qJ792zcmaiuOj9LYStka4
XdsMhCbZsH8PeVfU36z7DGlZZ0lay1dAgqH4lVYu+LAA55mNFB6CqHLKq/APnrk9
Iopuz8m7AA8yEQ4lrAvYtFY3OpKQpKv0VZhDTtrILj0io7JdTzWNAbD0EFJmr7po
YW3j+kuRCTEUK0c4wD00mU5ZAytEdjgZuKQSTnfbEbrzOxSOvY+6E5a4B+SnqA0D
BciowS1par9BQDTZUsKnYPUIa0qySg==
=CtoI
-----END PGP SIGNATURE-----

[qubist]

On Mon, 25 Mar 2024 12:45:17 +0100 Marek Marczykowski-Górecki wrote:

> IMO the main advantage of the single table approach is purely
> port-based rules (UDP or TCP), but the default firewall doesn't have
> many of them. They may be relevant for custom-input chain (but not
> always - sometimes you might want to use IP address in those too),
> and rarely for custom-forward.

What do you mean? Using an IP address is possible in inet table too.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, but you need separate rules for IPv4 and IPv6 anyway, so the
benefit of combined table is minimal.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBcogACgkQ24/THMrX
1ywrjAf/Uc7SvayVEarHjEKQ9bZDqCPp0+5bOYDFVhSgvLYzVjchku/teYehAtVJ
Pe1LMrdeawIDUk2va3VCldS5zpjEoABDG68a2e4AR3QSFbw3pT4QlpH/0FiTOD1j
aDjs2INgChAFi0hinw7oDt2H89IFc0ZQcFZhYhYR/3R8oZEJDoMAhazP4cAZnkI+
gaHCuptr0BP8nNVRsj6pjPLm779PD2821uF/jIKZIW+hTuG5xvmIQ9/d0XPvC6th
APbkUUzFOeII+D0sHO7F6/SlrBxMV6iqdoUwOG7sWKGUTW5FdgA92/OOOl6vGj8C
xllZmVSwKkMedB41HnMkS5eLHiB+IA==
=LcEW
-----END PGP SIGNATURE-----