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: <55a4f86e0910140051v69441b09gd364b32f8e2d0c68@mail.gmail.com>
Date:	Wed, 14 Oct 2009 00:51:56 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	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'm thinking that the mark should be a tunnel parameter with values of
inherit or a constant.

The reasoning being that this allows you to mark all packets leaving
on a tunnel with a specific value and you can then use that mark to
use a different routing table just for that tunnel.

The default routing table could point at the tunnel, and if the tunnel
is marked than the mark on those packets could make them not use the
default routing table, and instead use a routing table which is closer
to physical network layout.

I believe nowadays you usually solve this by having an explicit route
for the other endpoint of the tunnel in the main routing table...
which means you can't actually tunnel the normal traffic directed at
the other endpoint of the tunnel.
This would fix that.
--
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