TBTF for 1996-09-23 [1]

Earlier reports of the untimely death of the Internet turn out to have been exaggerated. SYN flooding, while a serious denial-of-service threat, is yielding to strenghtened Unix kernel code. Solutions have been developed and are being distributed for at least BDSI, FreeBSD, Linux, and SGI kernels. Here is a summary of the current state of affairs from Alexis Rosen <alexis at panix dot com>, founder and operator of Panix, which fought off the first known SYN flooding attack. (Rosen's comments were sent to the MEME list as a followup to coverage there of the attacks on Panix.)

> By now, based on work done by me, Avi Freedman, and a few others,
> most modern Unixes have or will shortly have fixes that will protect
> them against even serious attacks... So far these countermeasures
> have been effective against all real-life attacks. I expect them to
> continue to be so in the future... Still, ...there's a whole class
> of attacks possible with source-IP spoofing. Some are *much* worse
> than SYN attacks.

For a more technical look at how some of these Unix solutions developed over the period from 9/18 to 10/5, see these notes [2] by Vernon Schryver's <vjs at sgi dot com> postings appear on the TBTF archive by permission.

I haven't seen any reports of work to arm Windows NT or Macintosh servers against SYN-flooding attacks, but I assume such work is going on.

[1] <http://www.tbtf.com/archive/1996-09-23.html>
[2] <http://www.tbtf.com/resource/schryver.html>

TBTF for 1996-07-02 [3]

On 1996-10-07 Marimba [4], the company founded by four Java pioneers from SunSoft, finally took the wraps off their development work. "Castanet" bids to revolutionize the way applications and information are delivered over the Web. Followers of intranet technology are as excited about Castanet's potential for inhouse software distribution as about its commercial prospects on the wider Web. For good general coverage see [5] and [6]; Marimba's descriptive white paper is at [7].

Castanet defines a new kind of object called a "Channel": something like an application with a pipe attached, so it can receive updated data or software. "Tuner" software, which runs on your client machine, lets you attach to Channels served by Transmitter software running on a Web server. Other Castanet components, Repeaters and Proxies, allow the technology to scale to support large intranets with firewalls. All of the Castanet component pieces are written in Java.

The Tuner manages the storage of code and data on your client machine, so Java applets can become persistent objects that you don't need to download each time you use them. HotWired is taking advantage of this Castanet feature in their beta implementation of a chat room [8]. Excite, Inc. is developing a Channel Guide to help you find and preview Channels of interest (but there's no sign of it on their site at this writing).

The Castanet tuner is available in a preliminary version for free download [9] for Windows 95, Windows NT, and Solaris 2.x platforms. Macintosh is promised soon but no dates are given.

[3] <http://www.tbtf.com/archive/1996-07-02.html>
[4] <http://www.marimba.com/>
[5] <http://www.sjmercury.com/business/compute/marimba1006.htm>
[6] <http://www.news.com/News/Item/0,4,4149,00.html>
[7] <http://www.marimba.com//products/castanet.html>
[8] <http://www.talk.com/talk/index.html>
[9] <http://www.marimba.com//products/download.html>

TBTF for 1996-05-20 [10] TBTF for 1996-07-14 [11]

If the White House's third try [10] at pushing key escrow was the Grandson of Clipper, and their fourth [11] the Great-Grandson of Clipper, we seem now to be faced with the Great Grand-Nephew of Clipper [12]. And it's got legs. Instead of requiring that crypto keys be escrowed, the new proposal requires that they be "recoverable" using new technology under development by IBM and an alliance [13] that includes DEC, Sun, Apple, and, surprisingly, RSA -- but not Microsoft and not Netscape. Under the new proposal, export controls would be moved from the State Department to the Commerce Department, but the FBI would enjoy veto power over proposed exports. Companies that commit to key recovery would be allowed to export 56-bit crypto immediately (up from the 40 bits currently allowed), and unlimited key lengths after two years, providing that key recovery provisions are in force. A Netscape spokesman was quoted [14] as calling the proposal "tantamount to making public policy by extorting high-tech companies."

[10] <http://www.tbtf.com/archive/1996-05-20.html>
[11] <http://www.tbtf.com/archive/1996-07-14.html>
[12] <http://www.epic.org/crypto/key_escrow/key_recovery.html>
[13] <http://www.news.com/News/Item/0,4,4063,00.html>
[14] <http://www.nytimes.com/web/docsroot/library/cyber/week/1002code.html>

Today Concentric Network Corp. won an injunction [15] against Cyber Promotions, Inc. -- the outfit against which AOL lost a court fight to keep its subscribers free of email spam -- see TBTF for 1996-09-08 [16]. Cyber Promotions, it seems, was forging a Concentric Network return address in their spams, so thousands of outraged Netizens bombarded the ISP daily with demands that Concentric stop supporting an activity that is, in fact, forbidden by its terms of service and of which Concentric was entirely innocent. The wording of the promise that Cyber Promotions was compelled to sign forbids them specifically from thus abusing Concentric in the future. It seems to me that the spammer will be free to choose another ISP "goat," or to forge a nonexistent return address on their future spams, without penalty. This timely news just arrived on Glen McCready's <glen at qnx dot com> "0xdeadbeef" mailing list.

[15] <http://home.concentric.net/press/spam.html>
[16] <http://www.tbtf.com/archive/1996-09-08.html>

Here's a suggestion for residents of the UK to get relief from email spam. Bernard Peek <bap at intersec dot demon dot co dot uk> proposed this tongue-in-cheek remedy in RISKS. Now all he has to do is get AT&T, Sprint, et al. to cooperate.

> In the UK we have a Computer Misuse Act which makes it an offence
> to alter any data on any computer without proper authorisation. If
> I declare that unsolicited e-mail advertising to this node is un-
> authorised (and this I hereby do) then anyone sending such mail to
> me is committing a criminal offence. The US telephone service is
> required, under international treaties, to prevent this.

TBTF for 1996-04-07 [17]

Charles Platt's book Anarchy Online [17] experienced delays to its publishing schedule, so Platt took matters into his own hands. He designed, typeset, and paid for a hardcover run of the book, then sold the designs and typeset masters to HarperCollins for use in the softcover when it comes out. See [18] for excerpts from Anarchy Online. Platt is selling the hardcover edition at a special price to Netizens; see [19] for details. To order the book you can call 1-800-xxx-xxxx (from the U.S. only).

[17] <http://www.tbtf.com/archive/1996-04-07.html>
[18] <http://charlesplatt.com/extracts.html>
[19] <http://charlesplatt.com/info.html>
[19a] <http://www.amazon.com/exec/obidos/ISBN=0061009903/tbtfA/>

He was Hungarian by birth, a child prodigy, arguably the finest mathematician of the 20th century, certainly one of its most prolific and gregarious. He was eccentric and itenerant, prone to turning up in some city where he was to speak carrying a suitcase (the totality of his possessions in the world) and calling some local mathematician to say, "My brain is in town." Said local mathematician would put him up (and put up with him) with good humor and perhaps a touch of awe. A visit from Erdös meant that a young mathematician might move up in the rankings of Erdös Numbers [20]. Paul Erdös himself had Erdös Number 0. Those who have ever co-authored a paper with him are of Erdös Number 1; as of May 1996 there were 462 such. Those who have published papers with EN1 mathematicians are EN2; and so on. Erdös published some 1,400 papers, a self-described "machine for turning coffee into theorems." Unlike Andrew Wiles [21], who secluded himself for years to prove Fermat's Last Theorem, and unlike Ramanujan [22], who at his untimely death left notebooks filled with cryptic and beautiful, but unproven, theorems -- unlike these bolt-from-the-blue mathematicians Erdös worked in the open light of constant collaboration. He died on September 20.

[20] <http://www.acs.oakland.edu/~grossman/erdoshp.html>
[21] <http://www.maa.org/mathland/mathland_6_10.html>
[22] <http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Ramanujan.html>

The TBTF mailing of 1996-09-23 went out to 1481 email addresses. Any mailing of this size will result in bounce messages. Some of these indicate transitory conditions and can be ignored, while others flag expired email addresses, servers that have moved, etc. These latter messages should spur the list maintainer (me) to prune the list, unless I want to field similar messages after every future mailing.

My usual habit is to deal with the bounces as they come in, noting some for eventual action and deleting the messages as I go. For the 9/23 issue I decided to save every bounce message the mailing generated. Forty-six arrived over the ensuing 6 days -- above 3% of the total size of the mailing list -- occupying 362 KB on my disk. This seems like a lot to me, though I suspect that some mailing lists are far "dirtier." By the time of the next mailing (the survey on 9/29) I had deleted 51 nonfunctioning email addresses from the list.

The list maintenance process is a relentlessly manual one. Bounce messages come in so many forms and formats that they easily defeat attempts to sort or filter them. And it's hard to imagine how you could automate the task of discriminating which of the bounces require action and which are mere annoyances.

The most intriguing of the bounces was this aftershock of the commercialization of the Internet backbone. Sprint is saying "You can't get there from here."

 Your message was not delivered to (suppressed)@(supressed).sprint.com
        for the following reason:
        Incompatibility between two sites on the route of the message
        (please contact local administrator)
        Authorisation failure at site 'gateway.sprint.com' for recipient
        '(supressed)@(supressed).sprint.com' Reason: This route is
        prohibited: (policy none)