netdev - Re: [PATCH] Add sk_mark route lookup support for IPv4 listening sockets, and for IPv4 multicast forwarding

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <55a4f86e0910141133y4decdeb4v43d9168687bbb724@mail.gmail.com>
Date:	Wed, 14 Oct 2009 11:33:39 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	steve@...gwyn.com
Cc:	David Miller <davem@...emloft.net>, atis@...rotik.com,
	netdev@...r.kernel.org, panther@...abit.hu, eric.dumazet@...il.com,
	brian.haley@...com
Subject: Re: [PATCH] Add sk_mark route lookup support for IPv4 listening 
	sockets, and for IPv4 multicast forwarding

> I don't agree. There are two route lookups with a tunnel, the
> internal one and the tunnel one. Here is an example of what I'm
> thinking:
>
> 1. Look up a route which points at a remote ip addres via a tunnel device.
>   The "setmark" on this route sets the skb mark

imho, this is much better done by having the mark setting performed
explicitly by the tunnel device itself.
That's also were we set ttl and qos (or inherit) on the outgoing packet).

> 2. Look up a route on the tunnel itself (i.e. the tunnel endpoint not
>   the socket endpoint) using the mark from the initial lookup. This
>   route can depend on the previous lookup (if there are multiple
>   routes for multiple marks) and also set the mark to use.

we would get the mark set by the tunneling module here.

> The default would be to inherit the mark over a route lookup, in
> case that no "setmark" had been specified for that route. In
> other words, it would be the same as it is now.

I'm not saying your solution wouldn't work, but I think it's less
clean.  I don't think marking should be inherited (in the general
case) in case of packet wrapping (whether via gre, ipip, sit, or other
methods).

> The mark is supposed to be a generic thing, not just for routing
> lookups, it can be used for classification, etc as well. I would
> expect to see such a thing used for maybe specifying a VLAN or
> a reference to an MPLS label stack, or something similar too,

Right, the mark can currently (as far as I know) be set in one of two
ways - either from the mangle table (and it can also be matched on in
netfilter) or by using setsockopt(SO_MARK).

Imagine a situation where you have a machine with routing already
configured (pretty complex setup, tunnels, firewalls, etc) and you
want to run a user space application that verifies (health-checks)
some remote host (or something).  As part of the health check you want
to verify a particular route to the destination.  This requires
per-socket routing, which can (almost) be achieved by having proper
routing (on fwmark) setup and using setsockopt(SO_MARK) on the health
check socket in order to force specific routing.  These health checks
may then of course be feedback into the routing system (ie. if they
fail the routing rules get modified).  Note, that in particular we may
want to be healthchecking routes that aren't even available in the
default routing table (because they've currently been removed from the
default table, because previous health checks failed).

Maciej
--
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