On 26.05.2016 20:42, Tom Herbert wrote: > On Mon, May 23, 2016 at 11:11 AM, Tom Herbert <t...@herbertland.com> wrote: >> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan >> <sowmini.varad...@oracle.com> wrote: >>> >>>>> 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 :-) >>> >>>> On 21.05.2016 19:46, Sowmini Varadhan wrote: >>>>> Do you mean this >>>>> http://www.ietf.org/mail-archive/web/spud/current/msg00365.html >>> >>> On (05/22/16 03:08), Hannes Frederic Sowa wrote: >>>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw >>>> extension headers mentioned but haven't grasped why they deem necessary. >>> >>> Tom should clarify what he meant, but perhaps he was referring to other >>> threads discussing v6 EH. In any case, I dont think the way least-privileges >>> for EH are implemented in an OS is directly relevant or causational for >>> whether or not the kernel should be bypassed - looks like there are a lot >>> of other drafts floating around, arguing for implementing various tcp/ip >>> protocols in uspace and beyond, motivated by various reasons. >>> >> It's a deployment conundrum. Suppose tomorrow that IANA registers some >> new hpb option that would be useful to the network, but is of no >> interest to the kernel other than it needs to be set in packets when >> the user requests it. In the white list model, there is no problem >> getting support for such a thing into the upstream kernel, the time >> frame for that is one release cycle. Neither is there any problem >> updating the apps to set the option, for instance we can update FB app >> to do this within a week. The problem is that getting something into >> the kernel does not make it useful, the kernel needs to actually be >> deployed which is mostly out of our control (for those of us who don't >> own the client platform). So get the options deployed on clients >> (particularly Android), this takes much, much longer. And if the >> feature requires explicit action do be enabled, like turning a sysctl, >> it is going to take even longer possibly an indeterminate amount of >> time to ever get enabled. >> > Thinking about this some more, the per option white list is a better > approach. If we allow an open ended mechanism for applications to > signal the network with arbitrary data (like user specified hbp > options would be), then use of that mechanism will inevitably > exploited by some authorities to force user to hand over private data > about their communications. It's better to not build in back doors to > security...
Sorry, Tom, can you try to explain again, I think I might not have understood you correctly. Thanks, Hannes
