netdev - Re: [PATCH] net: reflect the fwmark for replies with no socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Mar 2014 10:36:03 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Julian Anastasov <ja@....bg>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] net: reflect the fwmark for replies with no socket

On Wed, Mar 12, 2014 at 5:52 AM, Julian Anastasov <ja@....bg> wrote:
>         If you can do it with CONNMARK save+restore,
> do not change behavior for existing setups. It is
> hard to predict how the mark is used in ip and
> POST ROUTING rules.

I think CONNMARK save/restore can do some of this but not all of it.

For example, consider the case of mark-based routing ("ip rule add
fwmark 123 lookup 456"). Setting the mark when emitting the packet
from protocol code (i.e., this patch), will cause the right route to
be selected. This will properly follow the routing policy chain
(including match routes like "unreachable" and "prohibit" if present),
use the right MTU, select the right source address for ICMP errors,
pick the right MSS/rwin for inclusion in SYN+ACK packets, and so on.

Some of this can be done after the fact using a combination of the
route target, snat/masquerade, MSS rewriting, and so on. However, that
essentially requires duplicating routing and source address selection
into iptables rules. This is brittle and particularly difficult when
dealing with IPv6, where routes can come from autoconf and source
address selection is more complex than in IPv4. It also requires using
snat/masquerade for IPv6, which is something we should avoid if
possible. In general rule it seems to me that it's better to have the
kernel emit the correct packet the first time around than having to
use iptables CONNTRACK to fix it up after the fact.

How much of a concern is modifying existing behaviour? Personally I
think reflecting the mark is better than just using 0 all the time,
but of course, it's possible that people are explicitly matching mark
0 in firewall rules or routing tables. Would it be better if this was
a sysctl?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html