netdev - Re: [PATCH RFC iproute2] iplink: Support envhdrlen

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: <9ed8fc87-85ba-c25f-1212-127aba0e9272@gmail.com>
Date:   Sat, 1 Oct 2016 01:49:53 +0900
From:   Toshiaki Makita <toshiaki.makita1@...il.com>
To:     Jiri Benc <jbenc@...hat.com>,
        Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
Cc:     netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Vlad Yasevich <vyasevich@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH RFC iproute2] iplink: Support envhdrlen

On 16/09/29 (木) 21:49, Jiri Benc wrote:
> On Tue, 27 Sep 2016 17:55:40 +0900, Toshiaki Makita wrote:
>> This adds support for envhdrlen.
>>
>> Example:
>>  # ip link set eno1 envhdrlen 8

Thank you for taking a look at this.

> I don't see why this should be user visible, let alone requiring user
> to set it. This should be transparent, kernel should compute the value
> as needed based on the configuration and set it up. Requiring the
> administrator to pick up a calculator and sum up all the vlan, mpls and
> whatever header lengths is silly.

I'm thinking both in-kernel automation (for VLAN) and users' manual 
operation are necessary. In fact, as I stated in the cover letter, my 
first implementation was an automation-based approach. Actually 
automation is advanced form of this feature so I'm proposing this very 
basic feature first.

> I realize that we currently have no easy way to do that. Especially
> with lwtunnels and stuff line MPLS where we don't easily know the
> number of tags. But every uAPI we introduce will have to be supported
> forever and going a particular way just because it is easy to implement
> is not sustainable.

It may be possible for MPLS lwtunnel to notify underlying device of 
needed header length. But at this point MPLS does not allow encapsulated 
packets to be greater than MTU of underlying device. So how to determine 
if someone wants to leverage envhdrlen instead? Add a knob to lwtunnel 
layer? Then, add another knob to l2tp, iptunnel, or anything like that? 
At least full-automation does not look possible other than VLAN (which 
by default requires envhdrlen expansion), so anyway manual operation is 
needed in some form.
Another use-case is reducing envhdrlen. We can expand it on creating 
VLAN device automatically, but cannot decrease the size because there 
could be other consumers of envhdrlen.

> At the very least, it should be configurable from the other direction.
> I.e. telling which interfaces can be used by vlans or MPLS (if it
> cannot be inferred automatically) and configuring maximum number of
> tags on the given vlan/mpls/whatever interface/route/whatever.

Probably I don't get your point...
Are you suggesting something like this?
$ ip link set eth0.10.20 expand-realdev-envhdrlen
or like this?
$ ip link set eth0 allowed-vlan-tags 2

Toshiaki Makita