netdev - Re: IPv6 extension header privileges

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

Date:	Fri, 27 May 2016 11:53:46 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Tom Herbert <tom@...bertland.com>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

On 26.05.2016 20:42, Tom Herbert wrote:
> On Mon, May 23, 2016 at 11:11 AM, Tom Herbert <tom@...bertland.com> wrote:
>> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan
>> <sowmini.varadhan@...cle.com> wrote:
>>>
>>>>> Tom Herbert wrote:
>>>>>>>>> If you don't mind I'll change this to make specific options are
>>>>>>>>> privileged and not all hbh and destopt. There is talk in IETF about
>>>>>>>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>>>>>>>> allow setting EH. I would like to avoid that :-)
>>>
>>>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>>>> Do you mean this
>>>>>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
>>>
>>> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>>>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>>>> extension headers mentioned but haven't grasped why they deem necessary.
>>>
>>> Tom should clarify what he meant, but perhaps he was referring to other
>>> threads discussing v6 EH. In any case, I dont think the way least-privileges
>>> for EH are implemented in an OS is directly relevant or causational for
>>> whether or not the kernel should be bypassed - looks like there are a lot
>>> of other drafts floating around, arguing for implementing various tcp/ip
>>> protocols in uspace and beyond, motivated by various reasons.
>>>
>> It's a deployment conundrum. Suppose tomorrow that IANA registers some
>> new hpb option that would be useful to the network, but is of no
>> interest to the kernel other than it needs to be set in packets when
>> the user requests it. In the white list model, there is no problem
>> getting support for such a thing into the upstream kernel, the time
>> frame for that is one release cycle. Neither is there any problem
>> updating the apps to set the option, for instance we can update FB app
>> to do this within a week. The problem is that getting something into
>> the kernel does not make it useful, the kernel needs to actually be
>> deployed which is mostly out of our control (for those of us who don't
>> own the client platform). So get the options deployed on clients
>> (particularly Android), this takes much, much longer. And if the
>> feature requires explicit action do be enabled, like turning a sysctl,
>> it is going to take even longer possibly an indeterminate amount of
>> time to ever get enabled.
>>
> Thinking about this some more, the per option white list is a better
> approach. If we allow an open ended mechanism for applications to
> signal the network with arbitrary data (like user specified hbp
> options would be), then use of that mechanism will inevitably
> exploited by some authorities to force user to hand over private data
> about their communications. It's better to not build in back doors to
> security...

Sorry, Tom, can you try to explain again, I think I might not have
understood you correctly.

Thanks,
Hannes