On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 21.05.2016 17:19, Tom Herbert wrote: >> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote: >>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote: >>>>> >>>>> There are some options inherently protocol depending like the jumbo >>>>> payload option, which should be under control of the kernel, or the >>>>> router alert option for igmp, which causes packets to be steered towards >>>>> the slow/software path of routers, which can be used for DoS attacks. >>>>> >>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the >>>>> whole CALIPSO model, etc. >>>>> >>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop >>>> >>>> "requires" is a strong word. 3542 declares it as a "may" (lower case). >>>> The only thing required strongly is IPV6_NEXTHOP itself. >>>> >>>> I suspect 3542 was written at a time when hbh and dst opt were loosely >>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY) >>> >>> My wording directly from the RFC was too strong, true, but given that >>> there is a CALIPSO patch already floating around for the kernel and >>> those options are strictly controlled by selinux policy and build the >>> foundation for the networking separation we can't make it simply >>> non-priv. >>> >> 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 :-) > > Hehe, certainly. > > A white list of certain registered IPv6 IANA-options for non-priv whould > certainly fly in my opinion. That is what I meant with "More > fine-grained parsing and setting of those options has never been > implemented." from my first mail. > > I am not that certain about a blacklist though, but haven't thought > about that enough. I didn't yet get around to review other options, but > basically people could use private options in some proprietary settings > and we could break their assumptions by such a change. > > Would a white list be sufficient? > Probably not. The "kernel is the problem" community always seem to be looking for even the slightest API or implementation deficiency to justify bypassing the kernel entirely. :-(
Tom > Bye, > Hannes >
