Security Assessment of the Transmission Control Protocol (TCP)

Fri Feb 13 22:01:21 UTC 2009

From: Fernando Gont <fernando at gont.com.ar>
>While many textbooks and articles have created the myth that the
>Internet protocols were designed for warfare environments, the top level
>goal for the DARPA Internet Program was the sharing of large service
>machines on the ARPANET.

This in itself has become an oft-repeated canard.

It is true that an important early rationalization for funding DARPA
network research was to allow researchers at different institutions to
use expensive (tens of millions of dollars) supercomputers from afar
and, thus, not have to buy every worthy researcher their own O($100M)
supercomputer center.

However, an advantage in choosing a packet protocol (eventually IP)
rather than a virtual circuit protocol as was popular around the time
of its inception (e.g., IBM's SNA) was that packets could be re-routed
around damage, transparently to virtual circuits built on top of the
underlying packet protocol (e.g., TCP.) Routing of packets could be
done dynamically on a per-packet basis if needed.

And it was observed that routing around damage could at least in
theory have utility in a situation where circuit facilities were being
damaged in warfare so long as some route between two points remained.

So these two goals are not mutually exclusive by any means.

Merly providing remote access to super-computer facilities could have
been accomplished with existing communication (e.g., phones and
modems) and networks (e.g., SNA.) There was no need to fund the R&D of
a new suite of protocols.

Further:

>As a result, many protocol specifications focus
>only on the operational aspects of the protocols they specify, and
>overlook their security implications.

This is a non-sequitar and not a result at all. Neither goal implied
security, only integrity.

This was not an oversight, security was, and to a great extent still
is, thought to be a higher-level function than packetizing and packet
routing, with a few exceptions where a potential security flaw truly
lies in the protocol (e.g., poor choice of packet sequence numbers.)

>While the Internet technology evolved since it early inception, the
>Internet?s building blocks are basically the same core protocols adopted
>by the ARPANET more than two decades ago.

Two decades is twenty years which takes me back to 1988.

Three decades would be more accurate, e.g., the great NCP changeover
which I think was 1978.

I suppose arguably three decades is "more than two decades".

>For some reason, much of the effort of the security community on the
>Internet protocols did not result in official documents (RFCs) being
>issued by the IETF (Internet Engineering Task Force).

(for some reason?)

To the best of my knowledge the reason is quite simple: That is not
what RFCs are used for tho occasionally some summary of the state of
the art appears in an RFC.

The rest seems reasonably stated.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*