Hi Alexander,
On Wed, Nov 22, 2023 at 12:17:49AM +0100, Alexander Zubkov wrote:
> > Can you think of a use-case where fpRPF isn't enough?
>
> Yes. IMHO, the problem with RPF is that routing table doesn't reflect the
> network topology, but only a subset of it.
Right that is the fundamental
Hi Daniel,
On Mon, Nov 20, 2023, 03:05 Daniel Gröber wrote:
> Hi Erin, Juliusz,
>
> On Sat, Nov 18, 2023 at 11:21:57AM +0100, Erin Shepherd wrote:
> > On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote:
> > > That would be a problem as I specifically want to tie the source
> address
> > >
Hi Erin, Juliusz,
On Sat, Nov 18, 2023 at 11:21:57AM +0100, Erin Shepherd wrote:
> On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote:
> > That would be a problem as I specifically want to tie the source address
> > filtering to this too. I'll have a look at the internals (if and) when I
> > get
> Is tying source address filtering to the routing table the right thing to do
> here? It seems to me that it would cause issues similar to those we see more
> generally with Unicast Reverse Path Filtering
Issues are caused by the kernel performing filtering that the routing
protocol is not aware
On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote:
> Hi Alexander,
>
> On Thu, Nov 09, 2023 at 12:57:26PM +0100, Alexander Zubkov wrote:
> > But as I understood the technology, it works only in one way (for
> > outgoing packets) and the decapsulation should be processed separately,
> > for
Hi Alexander,
On Thu, Nov 09, 2023 at 12:57:26PM +0100, Alexander Zubkov wrote:
> I heard recently about the lightweight tunnel infrastructure in Linux
> kernel (ip route ... encap ...). And I think this might be helpful in
> the context of this thread.
I hadn't seen that yet, thanks for
Hello all,
I heard recently about the lightweight tunnel infrastructure in Linux
kernel (ip route ... encap ...). And I think this might be helpful in
the context of this thread. Linux kernel allows already to add
encapsulation parameters to the route entry in its table. So you do
not need to
Hello!
On 8/29/23 00:13, Daniel Gröber wrote:
On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote:
I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer. Is
it because interfaces are expensive
Daniel, Kyle,
I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer. Is
it because interfaces are expensive in the Linux kernel? Or is there some
other reason why it is better to run all WG tunnels over a
Hi Kyle,
On Mon, Aug 28, 2023 at 11:40:48AM -0400, Kyle Rose wrote:
> On Sat, Aug 19, 2023 at 5:25 PM Daniel Gröber wrote:
> > Having read Kyle's use-case I'm thinking my original plan to extend the wg
> > internal source-address filtering to use a rt lookup with our new attribute
> > would not
Hi Steffen,
from the questions you ask I fear you've misunderstood my intention to
"replace" AllowedIPs. I'm strictly talking of the _implementation_
(allowedips.c) in Linux particular. The netlink interface would naturally
stay unchanged.
On Sat, Aug 19, 2023 at 10:00:17PM +0200, Steffen Vogel
11 matches
Mail list logo
