netdev - Re: [PATCH v8 net-next 0/9] ipv6: Extension header infrastructure

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 02 Jan 2020 13:41:38 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     tom@...bertland.com
Cc:     netdev@...r.kernel.org, simon.horman@...ronome.com,
        willemdebruijn.kernel@...il.com
Subject: Re: [PATCH v8 net-next 0/9] ipv6: Extension header infrastructure

From: Tom Herbert <tom@...bertland.com>
Date: Thu, 26 Dec 2019 14:51:29 -0800

> 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.

So, patch #1 is fine and it seems to structure the code to more easily
enable support for:

https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-07

(I'll note in passing how frustrating it is that, based upon your
handling of things in that past, I know that I have to go out and
explicitly look for draft RFCs containing your name in order to figure
out what your overall long term agenda actually is.  You should be
stating these kinds of things in your commit messages)

But as for the rest of the patch series, what are these "emerging
functionalities" you are talking about?

I've heard some noises about people wanting to do some kind of "kerberos
for packets".  Or even just plain putting app + user ID information into
options.

Is that where this is going?  I have no idea, because you won't say.

And honestly, this stuff sounds so easy to misuse by governments and
other entities.  It could also be used to allow ISPs to limit users
in very undesirable and unfair ways.   And honestly, surveilance and
limiting are the most likely uses for such a facility.  I can't see
it legitimately being promoted as a "security" feature, really.

I think the whole TX socket option can wait.

And because of that the whole consolidation and cleanup of the option
handling code is untenable, because without a use case all it does is
make -stable backports insanely painful.