On 21.05.2016 18:00, Tom Herbert wrote: > 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. :-(
Hmm, I see... 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. Bye, Hannes
