Re: [Spud] SPUD's open/close are unconvincing

[Toerless Eckert <[e-mail]>]

On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote:
> TCP should probably not happen in the kernel either. Nor should
> printer drivers be in the kernel or anything that does not require the
> intermediation of the security monitor.

Right. As an OS person i would love for someone to implement a
"raw transport socket" option for unprivileged processes. Implement
in linux, go to POSIX, spend a decade trying to get it proliferated across
OSs.

Alas, as a network person, i think this would be an exercise in futility
because the only real benefit would be to create connections between
a legacy kernel TCP stack and a new userland TCP stack and those
connections would likely be mostly have little benefits over a simple
old kernel to old kernel TCP stack:

If you want new functionalities, most of the time, both sides need to support
these, the fastest way to get both sides to support them is to both
run them in userland over UDP and once people get their minds around
the fact that this is good and not just a workaround, the interest in
"native TCP" for new improved transport functions should recede.

> Looking at the shoot-yourself-in-the-foot opportunities in the IPv6
> encoding, I am not exactly anxious to put all those untrusted code
> paths in a position where they can root the machine.
> 
> One of the main reasons the current generation of O/S are chronically
> insecure is that 90% of the stuff that is inside the security
> perimeter has no business being there.
> 
> At this point TCP is water under the bridge. But that does not mean we
> are obliged to remake the mistake.
> 
> When TCP was designed, the mantra was 'everything is a stream'. That
> was the right abstraction for Telnet and FTP and Mail. It is probably
> not the right abstraction for real time web where an unreliable
> sequence of chunks seems a better fit.

What's missing from SCTP ? 

Cheers
    Toerless