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

Powered by blists - more mailing lists