Reposted from Bill Frantz

[Jonathan S. Shapiro]

Your listserv won't let me post from work.  I won't be home all weekend, so
I'll ask you to deal with the issue manually

"Jonathan S. Shapiro" <jsshapiro@earthlink.net> wrote:
>> One interesting option is to allow TCP sessions to survive reboots of the
>> system.
>
>You can't.  There is a security issue.  Because the TCP connection is
>connection oriented, the endpoints tend to authenticate at the start
>and not thereafter.

TCP, even without any restart issues, is insecure in the mode you describe
because of TCP hijacking attacks.  In order to have TCP be secure, you need
to include MACs in the data stream.  Currently this security is the
responsibility of the application layer, although it can be passed off to
e.g. the IPSEC layer if IPSEC is implemented.

Steve Bellovin (sp?) has done a lot of work in this area.  I'll dredge up
references if you need them.

>
>Also, the TCP segments that both sides have agreed are transmitted are
>eagerly discarded.  You could keep the sequence numbers, but you
>wouldn't have the data to retransmit.

As a practical matter, I think the really interesting connections are the
ones that are idle.  However, if the sender rolls back, it still has all
the data.

>
>> If existing connections are to be torn down on reboot, the other end should
>> be notified.  Otherwise it may have a hanging connection.
>
>This is no different from the remote host going down.  TCP, at least,
>has well-defined timeouts for keepalive counters that guarantee
>reasonably fast teardown.  At the very least it is reduced to a
>previously solved problem.

TCP keepalive is a optional part of the protocol.

>
>The minute the downed host reboots the two sides will rapidly agree
>that the connections are stale.

Our problem comes with hosts that are assigned dynamic IP addresses.

>
>> How do you protect against Trojan horses in the network driver code?  Even
>> if you aren't trying to formally verify the kernel, you still want to get
>> informal assurance of correctness.  Making it larger won't help.  (But
>> being able to easily port existing code is damn attractive!)
>
>First, this is publicly examinable code.
>
>Second, removing the protocol code won't eliminate the network driver
>problem.

This is the problem which most worries me.  The whole idea that the way the
world work is to install some j-random code you got from the vendor of the
I/O gear where it can subvert the security of your system scares me silly
(from a security guru perspective).

Having protocol code in the kernel which is part of the kernel distribution
is much less scary.