netdev - Re: L2TPv3 offset

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

Message-ID: <40957000-591c-c871-ddf5-89e05fa958d0@katalix.com>
Date:   Tue, 19 Feb 2019 12:40:10 +0000
From:   James Chapman <jchapman@...alix.com>
To:     t.martitz@....de
Cc:     davem@...emloft.net, netdev <netdev@...r.kernel.org>
Subject: Re: L2TPv3 offset

On 19/02/2019 09:17, t.martitz@....de wrote:
>
> Hello,
>
> I saw that you removed the offset option from l2tp sessions in Linux
> 4.16 (commit 900631ee6a2651dc4fbaecb8ef9fa5f1e3378853 l2tp: remove
> configurable payload offset). Since we need something like that I'm
> reaching out to you.
>
Adding netdev.
>
>
> Our use case is pseudo-wire over l2tp, so we encapsulate ethernet
> within l2tpv3. This has lots of benifits for us, but one remarkable
> drawback is that the receiver, who's removing the encapsulation, will
> see a misaligned inner IP header.
>
> So we planned to use the offset to correct that. But I saw that the
> offset was removed not too long ago. Now I see that there is still
> "l2specific_len" / L2TP_ATTR_L2SPEC_LEN that we can use for pretty
> much the same purpose but I get the feeling that this should only be 0
> or 4 while we would need 2 or 6. I get this feeling because "ip l2tp"
> of the iproute2 package does not allow setting this at all and
> hardcodes 0 or 4 based on the type.
>
In L2TPv3, any payload offset would need to be implemented by defining a
new L2SpecificSublayer type since the L2TPv3 header has no offset field.
There are two standard L2TPv3 sublayers supported - None and Default.
These are fixed size (0 and 4 bytes respectively), hence the kernel now
ignores L2TP_ATTR_L2SPEC_LEN since the length can be derived from
L2TP_ATTR_L2SPEC_TYPE. For reference, the set of defined types are
listed at
https://www.iana.org/assignments/l2tp-parameters/l2tp-parameters.xhtml#l2tp-parameters-37.
No L2SpecificSublayer type was ever defined for L2TPv3 to allow a
configurable payload offset in ethernet pseudowires.

>
> So my question is what should we do know? Being based on removed
> functionality is kind of bad, but we must fix the misaligned inner ip
> header.
> We control the sender and receiver so we could apply all kinds of
> hacks, but we would rather find a solution compliant with the Internet
> community.
>
If you really need to insert padding in transmitted L2TPv3 packets
between the L2TPv3 header and its payload, one option is to define a new
L2SpecificHeaderType and patch the kernel to accept it.

If you control both the sender and receiver, is using FOU an option?

James