Re: Recent troubles

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

Someone replied to my

> > If I had source, I'd probably corrupt tcp_iss on not only received
> > packets but also [...].

with

> You should read RFC 793 (if you haven't).

This was all; there was no indication _what_ in RFC793 was felt
relevant.  (RFC793 is the TCP spec.)

I assume the section being talked about is the following part of 3.3;
this is a serious enough point that I think it's worth sending this to
the whole list, especially since I didn't mention this with the code I
posted.

+----------------
| Initial Sequence Number Selection
|
| The protocol places no restriction on a particular connection being
| used over and over again.  A connection is defined by a pair of
| sockets.  New instances of a connection will be referred to as
| incarnations of the connection.  The problem that arises from this is
| -- "how does the TCP identify duplicate segments from previous
| incarnations of the connection?"  This problem becomes apparent if
| the connection is being opened and closed in quick succession, or if
| the connection breaks with loss of memory and is then reestablished.
|
| To avoid confusion we must prevent segments from one incarnation of a
| connection from being used while the same sequence numbers may still
| be present in the network from an earlier incarnation.  We want to
| assure this, even if a TCP crashes and loses all knowledge of the
| sequence numbers it has been using.  When new connections are
| created, an initial sequence number (ISN) generator is employed which
| selects a new 32 bit ISN.  The generator is bound to a (possibly
| fictitious) 32 bit clock whose low order bit is incremented roughly
| every 4 microseconds.  Thus, the ISN cycles approximately every 4.55
| hours.  Since we assume that segments will stay in the network no
| more than the Maximum Segment Lifetime (MSL) and that the MSL is less
| than 4.55 hours we can reasonably assume that ISN's will be unique.
+----------------

Yes, the tactic I described (and implemented) for generating
harder-to-guess ISNs violates this spec.  Like any method that
generates "random" ISNs, it runs the risk that old segments may be
mistaken for data on newly-established connections.

Several factors combine to make me ignore this risk.

First is that, assuming the method does generate reasonably random
ISNs, it's unlikely.  For a 4K maximum window size, it would require a
one-in-a-million coincidence (4G/4K), and even then it would have to
hit all the unlikely items below.  (For fat-pipe TCP, the chance is
higher; for a half-meg window, for example, it's more like one in
8192.)

Second is that it requires an unlikely coincidence for it to be
possible at all: one host must send out a segment, crash, reboot, reset
the old connection, establish a new one, and only then have the old
segment come wandering in from having taken the long way around.  I
don't think I've ever seen a Sun (my code was for Suns, remember) that
can reboot fast enough for the old segment to still be within its TTL.
I've never seen trip-time variance high enough to provoke this, either,
even if machines could reboot fast enough.

Third is that the new connection must use exactly the same port numbers
as the old.  Unless the other end of the connection crashes too, this
is extremely unlikely because it will have a TIME_WAIT socket sitting
around preventing this.

Fourth is the quiet time on TCP reboot, specifically for old segments
to run out of TTL.  If and when machines reboot fast enough for this to
be a problem, their TCPs need to be taught about this anyway, and that
should take care of it.

Thus, I'll take the resistance to known attacks over the small risk
that two simultaneous host crashes, a very peculiar routing glitch,
extremely accelerated reboots, and a fluke somewhere between one in
8192 and one in 2^20 all conflue to corrupt a connection.

You may choose differently.  You're welcome to.

Unless of course you can suggest some better solution, something I can
implement in (say) less than 48 hours (my defense was done the same
afternoon I did the defense against LKMs and /dev/*mem).  I agree that
TCP needs to be redesigned...but that's not much help when machines are
being attacked _today_.  I'll be glad to talk redesign, once I have
some insulation against existing crackers.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu