Re: IPv6 extension header privileges

[Tom Herbert <tom@herbertland.com>]

On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On 21.05.2016 17:19, Tom Herbert wrote:
>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>> <hannes@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
>