netdev - Re: [PATCH] ipv6: allow bypassing cross-intf routing limits

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: <CA+BoTQ=8fbfQ9WuY=2+O-_uCu4qFJj33a3fTD_K4OC2HLD=J_A@mail.gmail.com>
Date:	Mon, 18 Apr 2016 11:38:42 +0200
From:	Michal Kazior <michal.kazior@...to.com>
To:	David Miller <davem@...emloft.net>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH] ipv6: allow bypassing cross-intf routing limits

On 17 April 2016 at 00:49, David Miller <davem@...emloft.net> wrote:
> From: Michal Kazior <michal.kazior@...to.com>
> Date: Thu, 14 Apr 2016 14:46:28 +0200
>
>> There are some use-cases to allow link-local
>> routing for bridging purposes.
>>
>> One of these is allowing transparent 802.11
>> bridging. Due to 802.11 framing limitations many
>> Access Points make it impossible to create bridges
>> on Client endpoints because they can't maintain
>> Destination/Source/Transmitter/Receiver address
>> distinction with only 3 addresses in frame header.
>>
>> The default behavior, i.e. link-local traffic
>> being non-routable, remains. The user has to
>> explicitly enable the bypass when defining a given
>> route.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@...to.com>
>
> Sorry, whilst I realize your problem, I'm not going to add what is
> explicitly a violation of the way link-local addresses are meant to
> work and the very much intentional restrictions the RFCs place upon
> them (they MUST not be routed).
>
> I also didn't see any real discussions in response to your original
> proposals, not from even one person I know is knowledgable about ipv6
> and the implications your change would have, and that is extremely
> troubling.
>
> I tried to let your patches sit for several days in order to let that
> kind of discussion happen, but it didn't.

I totally understand. Thanks anyway.


> So, you'll need to find another way to achieve your goals.

Hmm.. I actually do have another idea in mind already.

I was wondering about about implementing a link device in a similar
fashion to macvlan, bridge, et al, i.e. the device would take an
interface (wlan interface in my case) as a slave and perform L2
address mangling (which should be enough to accommodate the addressing
deficiency in wireless client modes). The device would obviously need
to do some L3/L4 packet inspection and manipulation.

Would something like that be acceptable? Thoughts?


Michał