netdev - Re: [PATCH v9 net-next 0/6] exthdrs: Make ext. headers & options useful

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]

Date:   Sun, 5 May 2019 08:42:08 -0700
From:   Tom Herbert <tom@...ntonium.net>
To:     David Miller <davem@...emloft.net>
Cc:     Tom Herbert <tom@...bertland.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH v9 net-next 0/6] exthdrs: Make ext. headers & options
 useful - Part I

On Sun, May 5, 2019 at 12:45 AM David Miller <davem@...emloft.net> wrote:
>
> From: Tom Herbert <tom@...bertland.com>
> Date: Mon, 29 Apr 2019 16:15:11 -0700
>
> > Extension headers are the mechanism of extensibility for the IPv6
> > protocol, however to date they have only seen limited deployment.
> > The reasons for that are because intermediate devices don't handle
> > them well, and there haven't really be any useful extension headers
> > defined. In particular, Destination and Hop-by-Hop options have
> > not been deployed to any extent.
> >
> > The landscape may be changing as there are now a number of serious
> > efforts to define and deploy extension headers. In particular, a number
> > of uses for Hop-by-Hop Options are currently being proposed, Some of
> > these are from router vendors so there is hope that they might start
> > start to fix their brokenness. These proposals include IOAM, Path MTU,
> > Firewall and Service Tickets, SRv6, CRH, etc.
> >
> > Assuming that IPv6 extension headers gain traction, that leaves a
> > noticeable gap in IPv4 support. IPv4 options have long been considered a
> > non-starter for deployment. An alternative being proposed is to enable
> > use of IPv6 options with IPv4 (draft-herbert-ipv4-eh-00).
>
> "Assuming ipv6 extension headers gain traction, my patch set is useful."
>
> Well, when they gain traction you can propose this stuff.
>
> Until then, it's a facility implemented based upon wishful thinking.
>
Hi Dave,

"Assuming" was probably the wrong word here :-). They are gaining
traction. A specific example is In-situ OAM (IOAM) which is being
heavily pushed by Cisco (draft-brockners-inband-oam-data-07). This
requires host to network signalling in data packets which goes far
beyond what information the IP header contains. Their first
inclination was to hack up UDP encapsulation protocols like Geneve,
but that fundamentally doesn't work for various reasons. We were able
to convince them that Hop-by-Hop Options is the correct mechanism so
they are pursuing that in
draft-ioametal-ippm-6man-ioam-ipv6-options-00. Naturally, they want to
support both IPv6 and IPv4 for their products, but there is no usable
mechanism in IPv4 (IP options are effectively obsoleted)-- hence the
motivation for back porting extension headers to IPv4.

In short, we're at a crossroads. Extension headers are "use it or lose
it". If we don't figure out how to make these usable and useful soon,
that may never happen and they'll be relegated to a historical
footnote just like IP options. IMO, it would be a shame if that
happens since we'd be surrendering a valuable feature.

Tom

> Sorry Tom, I kept pushing back using trivial coding style feedback
> because I simply can't justify applying this.
>