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]

Message-ID: <20160521174438.GA27990@oracle.com>
Date:	Sat, 21 May 2016 13:46:56 -0400
From:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Tom Herbert <tom@...bertland.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

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 :-)

Do you mean this
  http://www.ietf.org/mail-archive/web/spud/current/msg00365.html

Maybe I misunderstood that rather long thread, but the author of that
draft seems to be arguing for reinventing tcp congavoid and windowing 
on top of udp to bypass kernel? ;-)

Hannes Frederic Sowa wrote:
> >> A white list of certain registered IPv6 IANA-options for non-priv whould

Problem is that APIs are not IANA'ed. 
Even RFC 3542 is just Informationaal. 

And even the classic socket API's that come down from BSD are not 
ietf'ed or iana'ed.

Hannes Frederic Sowa wrote:
> Can you give some more details about the planned new options? I think we
> can also open the API up for all options where the fourth bit is set,
> which AFAIK denotes the experimental option space. And only have a
> blacklist for the fourth bit == 0 case. Otherwise this is something IETF
> people probably know more about what an impact this change could have.

I think it would be ok for some options to be privileged, others to not.
We certainly have precedent for that from the classic socket APIs..
and man pages etc can document any restrictions, as we do with other
ioctls/sockopts etc.

--Sowmini