netdev - Re: Source routing without rules?

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] [day] [month] [year] [list]

Message-ID: <20130828015158.GA1741@order.stressinduktion.org>
Date:	Wed, 28 Aug 2013 03:51:58 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: Re: Source routing without rules?

On Tue, Aug 27, 2013 at 06:46:35PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 27, 2013 at 6:14 PM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
> > On Tue, Aug 27, 2013 at 05:16:21PM -0700, Andy Lutomirski wrote:
> >> I'm about to implement a trivial source routing policy for the third
> >> time, and this is IMO stupid.  I want to have two routes to a network.
> >>  Each route should specify a src, and, if the flow matches the src,
> >> then that route should win.
> >>
> >> The rules that don't work are:
> >>
> >> ip route add <net> via <gw1> dev <dev1> metric 0
> >> ip route add <net> via <gw2> dev <dev2> src <dev2addr> metric 10
> >
> > src is actually the preferred src address. In ipv6 land there is a RTA_SRC
> > (look for ip route *from* parameter) route attribute settable to only
> > select routes if the from-source matches the route. If you implement
> > such a feature I would go with the same design (IPV6_SUBTREES).
> 
> Interesting.  The Kconfig help text for IPV6_SUBTREES is incredibly
> confusing.  What are the actual semantics?  I'm guessing that only
> routes that match the source address in their "from" clause are
> considered and ties are broken in favor of the longest from prefix.

At first normal longest-prefix lookup is done with the destination
address. The resulting fib6_node can now hold a subtree where a source
lookup will be done. If a node matches, this is the result. Otherwise
backtracking takes place in the "main" fib6_table.

Greetings,

  Hannes

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