Re: [tcpinc] Quick review of draft-rescorla-tcpinc-tls-option-04

[David Mazieres <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

>> The libc implementation won't work with unmodified applications, because
>> it will break when sharing/passing/inheriting file descriptors across
>> processes, a common pattern for Unix servers.
>>
>
> Hmm... I've seen designs where this should work, for instance where
> you dup the fds to point them to some intermediate location.

I'd like to see such a design.  I'm sure you can get something to work
with some application, but if the goal is all applications, then it's
going to be pretty tricky.

"dup the fds to point them to some intermediate location" sounds pretty
dubious to me.  For one thing the dup system call doesn't change what an
fd points to.  Now, if you mean point the file descriptors to some
intermediary daemon, then you are getting closer to a daemon
implementation, and by the time you fix it up, that's what you will
have.

But anyway not all applications are written in languages that use libc.
Not all applications are dynamically linked.  And not all C
implementations use libc--the standard recognizes both "hosted" and
"freestanding" implementations.  A big potential use case for TCPINC is
network file systems, which tend to be implemented with a freestanding C
compiler and supply their own libraries.  A daemon implementation would
encrypt NFS traffic, while a libc implementation likely would not.

This is not to say there isn't some valuable library-level use case for
TCP-ENO.  (In fact, that's partly why we left the door open to static
ENO options with multiple suboptions from host B, about which you are
skeptical.)  I just don't think such an implementation will satisfy
TCPINC.

David