Date:   Thu, 26 Dec 2019 13:12:11 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Simon Horman <simon.horman@...ronome.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH v7 net-next 0/9] ipv6: Extension header infrastructure

On Wed, Dec 25, 2019 at 4:19 PM David Miller <davem@...emloft.net> wrote:
>
> From: Tom Herbert <tom@...bertland.com>
> Date: Tue, 24 Dec 2019 09:55:39 -0800
>
> > This patchset improves the IPv6 extension header infrastructure
> > to make extension headers more usable and scalable.
> >
> >   - Reorganize extension header files to separate out common
> >     API components
> >   - Create common TLV handler that will can be used in other use
> >     cases (e.g. segment routing TLVs, UDP options)
> >   - Allow registration of TLV handlers
> >   - Elaborate on the TLV tables to include more characteristics
> >   - Add a netlink interface to set TLV parameters (such as
> >     alignment requirements, authorization to send, etc.)
> >   - Enhance validation of TLVs being sent. Validation is strict
> >     (unless overridden by admin) following that sending clause
> >     of the robustness principle
> >   - Allow non-privileged users to set Hop-by-Hop and Destination
> >     Options if authorized by the admin
>
> I see no explanation as to why we want to do this, nor why any of this
> is desirable at all or at any level.
>
> So as in the past, I will keep pushing back on this series because I
> see no real well defined, reasonable, impetus for it.
>
Hi Dave,

The fundamental rationale here is to make various TLVs, in particular
Hop-by-Hop and Destination options, usable, robust, scalable, and
extensible to support emerging functionality.

Specifically, this patch set:

1) Allow modules to register support for Hop-by-Hop and Destination
options. This is useful for development and deployment of new options.
2) Allow non-privileged users to set Hop-by-Hop and Destination
options for their packets or connections. This is especially useful
for options like Path MTU and IOAM options where the information in
the options is both sourced and synced by the application. The
alternative to this would be to create more side interfaces so that
the option can be enabled via the kernel-- such side interfaces would
be overkill IMO.
3) In conjunction with #2, validation of the options being set by an
application is done. The validation for non-privileged users is
purposely strict, but even in the case of privileged user validation
is useful to disallow allow application from sending gibberish (for
instance, now a TLV could be created with a length exceeding the bound
of the extension header).
4) Consolidate various TLV mechanisms. Segment routing should be able
to use the same TLV parsing function, as should UDP options when they
come into the kernel.
5) Option lookup on receive is O(1) instead of list scan.

Subsequent patch set will include:

6) Allow setting specific (Hop-by-Hop and Destination) options on a
socket. This would also allow some options to be set by application
and some might be set by kernel.
7) Allow options processing to be done in the context of a socket.
This will be useful for FAST, PMTU options.
8) Allow experimental IPv6 options in the same way that experimental
TCP options are allowed.
9) Support a robust means extension header insertion. Extension header
insertion is a controversial mechanism that some router vendors are
insisting upon (see ongoing discussion in 6man list). The way they are
currently doing it breaks the stack (particularly ICMP and the way
networks are debug), with proper support I believe we can at least
mitigate the effects of the problems they are creating.
10) Support IPv4 extension headers. This again attempts to address
some horrendous and completely non-robust hacks that are currently
being perpetuated by some router vendors. For instance, some middlebox
implementations are currently overwriting TCP or UDP payload with
their own data with the assumption that a peer device will restore
correct data. If they ever miss fixing up the payload then we now have
systematic silent data corruption (IMO, this very dangerous in a large
scale deployment!). We can offer a better approach...

Tom

Powered by blists - more mailing lists