netdev - Re: bridging with gre tunnel

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]

Date:	Mon, 14 Jul 2008 12:44:22 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	Philip Craig <philipc@...pgear.com>
CC:	bridge@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: bridging with gre tunnel

Philip Craig wrote:
> Timo Teräs wrote:
>> There is an essential difference in this patch compared to the one
>> I referred to. This patch adds a new way to create GRE devices which
>> results in ethernet style device whereas the older patch modifies
>> transmit and receive paths to detect packets coming from bridging
>> code and does not need userland changes at all.
>>
>> I kind of like the fact that userland tools work as-is and that
>> I don't need any special flags for the GRE tunnel creation. However
>> your patch does look way cleaner.
>>
>> Any comments on what the solution to merged in should look like?
> 
> I posted a cleaner version that's similar to what the old patch
> did, see http://marc.info/?l=linux-netdev&m=115449948503549&w=2

That's a third way to do it. The patch I referred to changed
ip_gre mostly (only change to bridging was the device type check).

But it has the same limitation that ether encapsulation is only
usable in association with bridging.

> But I don't think that is the right approach:
> - it forces you to use bridging if you only want ethernet over GRE
> - the change fundamentally has nothing to do with bridging

Yes, I would not do the ethernet header stuff in bridging code
either.

> Actually, this change doesn't really belong in GRE either, because
> that forces you to choose between ethernet encapsulation and not.
> It could be a new device that sits on top of GRE and simply does
> ethernet encapsulation then passes it to the raw GRE device.
> That's a lot of infrastructure for something so simple though,
> and I don't think people will want to use both devices at once.

This sounds as the most robust way to do it. But yes, it sounds
unlikely that both devices would be used simultaneously.

Not sure how easy it would be to add a new tunnel type. Apparently
they use IPPROTO_* to differentiate type and it would be the same
in this case.

Thanks for the feedback so far.
- Timo
--
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