- Test - lists.nanog.org

April 2000 COOK Report published on DDoS and Ideas of E. Gerck
by Gordon Cook 06 Mar '00

06 Mar '00

[since I haven't published a message here in about 3 years] Understanding Distributed Denial of Service pp. 1 - 16 During the second week of February the largest, and most diverse denial of service attacks in the history of the Internet caught several of the most important commercial web sites off guard and exposed what was previously a largely unsuspected operational vulnerability that affects the entire commercial Internet. -- Just as after Reagan was shot Al Haig stepped forward to say 'don't worry we're in charge here, we contend that Gene Spafford's February 19th summation of the White House meeting provides a soothing but superficial explanation of what is really a far more subtle and difficult structural weakness. This weakness is apparently inherent in the basic structure of the Internet and cannot be "enforced" out of existence. We present in Narrative form the NANOG and IETF technical discussions that resulted from the attacks. The discussion demonstrates that Internet backbone engineers are by no means agreed on precisely what happened or on how to deal with it. On February 9, Lauren Weinstein, partner to Peter G. Neumann of the Risks mail list and co-sponsor with Neumann of People for Internet Responsibility had the following observation. "It seems apparent that the rush to move all manner of important or even critical commercial, medical, government, and other applications onto the Internet and Web has far outstripped the underlying reality of the existing Internet infrastructure. Compared with the overall robustness of the U.S. telephone system, the Internet is a second-class citizen when it comes to these kinds of vulnerabilities. Nor will simply throwing money at the Internet necessarily do much good in this regard. More bandwidth, additional servers, and faster routers--they'd still be open to sophisticated (and even not so sophisticated) attacks which could be triggered from one PC anywhere in the world. In the long run, major alterations will be needed in the fundamental structure of the Internet to even begin to get a handle on these sorts of problems, and a practical path to that goal still remains fuzzy at this time." Ed Gerck's Ideas pp. 17- 22, 30 Part Two of this issue contains an interview with Ed Gerck as well as two essays by him. He is co-founder of the Meta Certificate Group, http://mcg.org.br , CEO of Safevote, Inc. and Chairman of the IVTA.. We suggest that his ideas form the basis for a fresh and compelling analysis of what we may really be dealing with. We conclude that there is a possibility that the fundamental nature of the attacks may have been completely misunderstood. We also contend that Gerck's theories, published here for the first time, may provide an entirely different mathematical basis for understanding the Internet as a quantum information structure possessing significantly different capabilities and potentials than could be extrapolated from our current understanding. Although this is quite a statement to make, his ideas have reached enough people so that it is likely that research will be rapidly undertaken to ascertain if his own experimental results dating from 1998 are verifiable and reproducible. Gerck's ideas involve the foundation of an entirely new calculus for the operation of the Internet. Gerck asserts that the major reason the attacks were so successful is that the packets arrived at the target servers with a high degree of coherency - that is to say at almost the same instant. He points out that the technical functionality of the Internet mitigates against the coherent arrival of large numbers of packets at a specific target and thus a ten fold spike in incoming bandwidth would be very unlikely unless other unusual mechanisms are also at play." How then could the observed effects of the arrival of very large numbers of packets have happened? He explains how his work in the quantum mechanics of lasers in the early 1980s gave him a hypothesis that he successfully tested in a university environment in 1998. Namely he suggests that the number of entities in the Internet has reached a critical mass where a single event such as a packet sent to a trin00 network, can result in an avalanche of coherent data amplification. The result is similar to the coherent amplification process that sets off the sudden flash of a laser. Under such conditions he posits that when this occurs, it creates conditions where packets can provide for a much different behavior as they reach a target. Gerck suggests that such events trigger a kind of quantum behavior, which however always exists but which then becomes visible at the user observed level and strongly contrasts with the classical behavior that it has replaced." Gerck's ideas represent a paradigmatic shift in the evaluation of the scope, function and behavior of the Internet. One of the problems of communications involved is that to those stuck in the old paradigm, messages defining the new are often unintelligible. For many people his ideas will be quite jarring. For example, his ideas reach to the root of what we call data. He suggests that data be thought of in terms of a natural quantity and as something that can be modeled with absorption, spontaneous emission and stimulated emission processes -- the last being a behavior associated with quantum systems. He finds that under certain conditions, stimulated data emission can win out over spontaneous data emission. This will happen when a minimum threshold of affected systems is disturbed by what may be a hacker attack, or the interaction of a virus with multiple systems or even by the unexpected appearance of a bug in operating software that everyone assumes to be stable. His findings lead to the conclusion that such perturbations, resulting in web site and or network congestion, will happen with increasing frequency. Of course if he is right, when they do happen the next time, they may have absolutely nothing to do with hackers. After compiling the technical discussion from NANOG and IETF, it seems to us that the emphasis on traditional security measures is rather futile. The Internet is too large with too many machines under too many levels of control for traditional security measures of confinement of people and machines to be effective. Gerck has some very interesting ideas about constructing mechanisms where two parties which are not known to each other may use a third neutral environment in which to securely negotiate conditions of trusted operation. He seems to have an uncanny sense of political power and psychology and how to reflect this in technical situations to build trust between parties that have no common grounds for negotiation. As recently as a week ago we intended to publish only his two essays. However when we called him on the 25th of February to ask for answers to questions about the second essay on coherency, we found ourselves in the midst of a far ranging discussion that opened up some of his ideas of the physics of data and mechanics of trust that we had not heard before. This discussion lead to the interview on pages 17 to 23. This interview which we have further expanded by asking several of our own experts to read and ask their own questions of Ed, begins to thrown some light on the breadth and scope of his ideas. Gerck's ideas lead to a paradigm change on such fundamental questions as data flow in the internet and the nature of security and trust in computer networking. Having a world view different from the prevailing gestalt often presents problems for everyone involved. We invite readers to ponder his message. We have known of Ed for perhaps almost two years and known him directly for six months. An unusual quality about him is that he is laid back. He is intuitive and skillful in dealing with people. His ideas may succeed precisely because he doesn't push too hard. We have been a bit gun shy about walking out on the end of a limb on behalf of the ideas of someone who is not yet well known and whose views are so iconoclastic. For the last few weeks we have made some serious efforts to get some sanity checks from people in better positions than we are to judge what he presents. Three very senior people have returned thumbs up. We introduced a forth such person with the strongest technical background of all to Gerck two weeks ago. When we asked this person how we might describe Gerck in this newsletter he replied: You might describe him as one of those bright people who are so frequently overlooked because he's happier working on hard problems than talking about it all. You might describe him as an Internet Guy who got here "the hard way" -- He's trained as a physicist. He thinks about the world from a perspective of how do you model the stuff you perceive around you in mathematical terms -- and this leads him to different observations than those made by those of us who "grew up" in the Internet and distributed computing in general." One of the problems facing the Internet, is that we have, sometimes with chewing gum and bailing wire, built it into something on which a very large proportion of our economy is riding. The prevailing opinion in the wake of the DDoS attacks is to call in law enforcement, build the security walls ever higher and hunker down with publicly reassuring words to the effect of don't worry we are in charge here. A careful reading of the technical discussion on pages 2 through 16 of this issue will show the that this position is founded on quicksand. A reading of the Gerck essays and interview will reinforce this conclusion We contend that the official views issued in the aftermath of the White House meeting of February may be well-intentioned. Nevertheless they are misguided. Without a correct diagnosis of our current problems, we will be unlikely to find solutions. As a result, the Internet's behavior of early February may become more rather than less commonplace. Essays, pp. 23- 27 Thinking We present roughly half of Ed Gerck's Thinking Essay in the belief that readers will begin to understand why we consider it the single best short essay on the topic of information control, DNS Governance and ICANN ever written. "...there is nothing to be gained by opposing ICANN, because ICANN is just the overseer of problems to which we need a solution. My point is that there is something basically wrong with the DNS and which precludes a fair solution - as I intend to show in the following text, the DNS design has a single handle of control which becomes its single point of failure. This needs to be overcome with another design, under a more comprehensive principle, but one which must also be backward-compatible with the DNS. [. . . .] So, the subject is domain names. The subject could also be Internet voting. But I will leave voting aside for a while. In my opinion, the subject, in a broader sense, is information control. If domain names could not be used for information control (as they can now by default under the DNS - see below), I posit that we would not have any problems with domain names. But, domain names provide even more than mere information control - they provide for a single handle of control. DNS name registration is indeed the single but effective handle for information control in the Internet. No other handle is possible because: (1) there is no distinction in the Internet between information providers and users (e.g., as the radio spectrum is controlled); (2) there is no easily defined provider liability to control the dissemination of information (e.g., as advertisement and trademarks are controlled); (3) there is no user confinement to control information access (e.g., as state or country borders in the Canadian Homolka case), etc. But, how did we end up in this situation? After all, the Internet was founded under the idea of denying a single point of control - which can be seen also as a single point of failure. The problem is that certain design choices in the evolution of the DNS, made long ago, have made users fully dependent on the DNS for certain critical Internet services. These design choices further strengthened the position of DNS name registration as the single handle of information control in the Internet. And, in the reverse argument, as its single point of failure. [. . . .] However, without the DNS there is no email service, search engines do not work, and web page links fail. Since email accounts for perhaps 30% of Internet traffic - an old figure, it may be more nowadays - while search engines and links from other sites allow people to find out about web sites in about 85% of the cases (for each type, see http://www.mmgco.com/welcome/ ) I think it is actually an understatement to call the DNS a "handle." The DNS is the very face, hands and feet of the Internet. It is the primary interface for most users - that which people "see". Its importance is compounded by the "inertia" of such a large system to change. Any proposal to change the DNS, or BIND nameservers, or the DNS resolvers in browsers in any substantial way would be impractical. [. . . .] One of other fallacies in email is to ask the same system you do not trust (DNS, with the in-addr.arpa kludge) to check the name you do not trust (the DNS name), when doing an IP-check on a DNS name. There are more problems and they have just become more acute with the need to stop spam. Now administrators have begun to do a reverse DNS check by default. Under such circumstances you MUST have both DNS and IP. Further, having witnessed the placing of decisions of network address assignment (IP numbers) together with DNS matters under the ruling of one private policy-setting company (ICANN), we see another example of uniting and making everything depend on what is, by design, separate. The needs of network traffic (IP) are independent of the needs of user services (DNS). They also serve different goals, and different customers. One is a pre-defined address space which can be bulk-assigned and even bulk-owned (you may own the right to use one IP, but not the right to a particular IP), the other is a much larger and open-ended name space which cannot be either bulk-assigned or bulk-owned. They do not belong together - they should not be treated together. But, there are other examples. In fact, my full study conducted with participation of Einar Stefferud and others has so far catalogued more than forty-one essential problems caused by the current design of the DNS. Thus, a solution to current user wants is not to be reached simply by answering "on what" and "by whom" control is to be exerted, as presently done in all such discussions, without exception - for example, those led by ICANN. In this view, ICANN is not even the problem (as usually depicted by many) but simply the overseer of problems. At least, of 41+ main problems - all of which involve information control. Thus by realizing both what these 41 and other problems are and the underlying issue of information control in the Internet (which issue is not ignored by governments), the study intended to lay the groundwork to provide for a collaborative solution to information flow in the Internet without the hindrance of these 41+ problems. The study also intends that the possibility of information control will be minimized as a design goal. [. . . .] Regarding "time" - readers may ask what is the schedule to propose new standards based on what I and my group are working on for domain names? As I see it and as I also comment in regard to the work on advancing standards for Internet voting at the IVTA (where IMO the same principles apply), time is not a trigger for the events needed to get us out of our predicament, but understanding is. Cooperation has its own dynamics and we must allow for things to gel, naturally. We can motivate, we can be proactive but we must not be dominating. We seek collaboration, not domination. Both technically as well as market-wise." Coherent Effects in Internet Security and Traffic Here is a paragraph from Gerck's second essay. "This was not only a DDoS - this was a CDoS. A Coherent Denial of Service attack. The difference is that a distributed but incoherent attack would not have done any major harm. In order to explain how such an attack was possible and why it was effective, one needs to understand first that, normally nothing is coherent in the Internet. All packets travel from source to destination in what may seem to be a random fashion; each host has unsynchronized time - oftentimes, even wrong time zones; and even the path traveled by each packet is also non-deterministic. Thus, achieving the coherent arrival of a stream of packets at one location by sending them from a large number of coordinated locations is a feat. **************************************************************** The COOK Report on Internet Index to 8 years of the COOK Report 431 Greenway Ave, Ewing, NJ 08618 USA http://cookreport.com (609) 882-2572 (phone & fax) Battle for Cyberspace: How cook(a)cookreport.com Crucial Technical . . . - 392 pages just published. See http://cookreport.com/ipbattle.shtml ****************************************************************

1 0

Quick fix
by Bandy Rush 04 Mar '00

04 Mar '00

I noticed that a number of individuals who post regularly to the NANOG mailing list have keyboards with malfunctioning shift keys. Since working keyboards are so expensive, far beyond the financial means of most poorly-paid technical workers, I humbly offer the following Perl program, which you can use to filter your NANOG e-mail to correct capitalization errors (procmail should do the trick for that). For example: i abhor cross-posting. but sometimes ... Gets converted to: I abhor cross-posting. But sometimes ... It's not perfect, but it catches most occurrances. If you have a slow computer, you probably want to disable the dictionary. You can do this by setting @DICT_FILES=(). As is, it is configured to search for the word list in the default locations in Linux and Solaris. And oh yes, it's a joke. ;) #!/usr/bin/perl -w # use good Perl form use strict; use English; # location of plain-text word list my @DICT_FILES = ("/usr/dict/words", "/usr/share/lib/dict/words"); # slurp in all input undef $INPUT_RECORD_SEPARATOR; my $input = <>; exit unless (defined($input)); # Fix end of paragraph $input =~ s/([a-z])(\n\n.)/$1.$2/g; # Fix start of sentence $input =~ s/(\n\n+)([a-z])/$1\u$2/g; $input =~ s/(\.\s+)([a-z])/$1\u$2/g; # Fix self-referental problems $input =~ s/(\b)i(\b)/$1I$2/g; $input =~ s/(\b)randy(\b)/$1Randy$2/g; $input =~ s/(\b)bush(\b)/$1Bush$2/g; # Fix words that should be capitalized (based on the dictionary) $INPUT_RECORD_SEPARATOR = "\n"; foreach my $dict_file (@DICT_FILES) { if (open(DICT, "< $dict_file")) { while (defined (my $uc_word=<DICT>)) { if ($uc_word =~ /[A-Z]/) { chomp($uc_word); my $lc_word = lc($uc_word); $input =~ s/(\b)$lc_word(\b)/$1$uc_word$2/g; } } last; } } # output our fixed text print $input; # The author releases this software into the public domain. -------------------------------------- AltaVista Smart is Beautiful http://www.altavista.com Raging Bull? Sleeping Bear? Live stock quotes at AltaVista Live! http://money.altavista.com --------------------------------------

7 6

Re: Quick fix
by Michael Shields 03 Mar '00

03 Mar '00

In article <Pine.GSO.4.21.0003030950480.5000-100000(a)benjy.onvoy.com>, Dan Boehlke <dboehlke(a)mr.net> wrote: > its not so much that my shift key doesn't work, that i gave it up to have > an extra meta key for emacs functions to be mapped to. :-) Microsoft was thoughtful enough to cause most new PCs to be shipped with three extra meta keys. Under X it is easy to start using them. -- Shields.

1 0

RE: Redstone
by Kevin Santamaria 03 Mar '00

03 Mar '00

Does anybody have opinions/information on the long term viability of the (former) Redstone product line? Thanks Kevin

1 0

noc@gblx and support@gblx both bounce...
by Steve Sobol 02 Mar '00

02 Mar '00

I just sent a message to noc(a)gblx.net about a possible routing problem. Mail to that address AND to support(a)gblx.net bounced. Isn't noc@ supposed to be a standard reporting address? Just wondering... **SJS -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, President, Chief Website Architect and Janitor sjsobol(a)NorthShoreTechnologies.net - 888.480.4NET - 216.619.2NET

3 2

Heads-up: Another whois change
by Kevin Day 02 Mar '00

02 Mar '00

NSI seems to have modified their WHOIS response format again, now including full information about each contact. Again, this broke one of my scripts since nothing is where it's supposed to be. Didn't they promise before to notify people before they did this again? Anyone else trying to process the response from a WHOIS should take note: # whois -h whois.networksolutions.com microsoft.com The Data in Network Solutions' WHOIS database is provided by Network Solutions for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. Network Solutions does not guarantee its accuracy. By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems). Network Solutions reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. Registrant: Microsoft Corporation (MICROSOFT-DOM) 1 microsoft way redmond, WA 98052 US Domain Name: MICROSOFT.COM Administrative Contact: Micosoft Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM Microsoft Corp One Microsoft Way Redmond, WA 98052 US 425 882 8080 Fax- - .: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM Microsoft Corp One Microsoft Way Redmond, WA 98052 US 425 882 8080 Fax- PATH Record last updated on 11-Dec-1998. Record created on 02-May-1991. Database last updated on 29-Feb-2000 21:55:34 EST. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS4.CP.MSFT.NET 207.46.138.11 DNS5.CP.MSFT.NET 207.46.138.12 I'm not sure if this is intentional or not, but it's really ugly. If it's a bug, yuck. Kevin

5 6

government eavesdropping
by Jeff Ogden 02 Mar '00

02 Mar '00

So what is the real story here? Is all, most, some of our international Internet traffic being intercepted by various governments? Is it only international traffic that is at issue or is domestic traffic within the US subject to routine eavesdropping without a court order? For years I've been telling people that while there was some risk that traffic on the Internet could be intercepted, that the risk was greatest at the ends of a connection and that as long as they were working with a reputable ISP that there was almost no risk that anyone was eavesdropping on the traffic from the more central networks. I've also been telling people that data "at rest" on disks or stored in servers is much more at risk than data "in motion" as it moves across the Internet. Have I been misleading people? -Jeff Ogden Merit >From http://dailynews.yahoo.com/h/ap/20000223/wl/eu_espionage_1.html > >Wednesday February 23 9:50 AM ET > >Report Details Vast Spy Network > >By CONSTANT BRAND Associated Press Writer > >BRUSSELS, Belgium (AP) - A U.S.-led communications >monitoring network is intercepting ``billions of messages per >hour'' including telephone calls, fax transmissions and private >e-mails, according to a European Parliament report made public >Wednesday. > >``We are not talking about a trivial thing here ... we cannot stop >them, they will continue,'' said Ducan Campbell, author of the >special parliament-commissioned report on the Echelon >spy-network. > >Campbell said that the intelligence network monitors and >intercepts sensitive European-wide commercial communications. >``The level of use is getting out of control,'' he told a packed >hearing of the Parliament's Committee for Justice and Home >Affairs. > >He said Canada, Britain, Australia and New Zealand are also >involved in Echelon. Other nations including France and Germany >also participate in a lower level in the spy-network which dates >back 50 years to the beginning of the Cold War. > >``The capacity of the filtering systems is enormous,'' Campbell >said. He added that most international internet communications >are being routed through the United States and through nine known >U.S. National Security Agency interception sites. > >Intelligence facilities located in the five countries can intercept fax, >e-mail or telephone communications easily he said. Campbell >urged the European Union to take action to protect against >unwanted interception of communications, which he said were >violations of human rights. > >Committee chairman Graham Watson said he wanted to be sure >the international surveillance system was not abusing its powers. > >Campbell said Microsoft, IBM, and a certain ``large American >microchip maker'' were providing certain product features which >allow the interception of information flow. > >Campbell said he did not know whether the U.S. corporations were >benefitting from the information gathering but said previous >commercial espionage resulted in the collapse of several European >contracts in the airline industry - both military and commercial.

13 13

Re: Alternative to BGP-4 for multihoming?
by Paul Vixie 02 Mar '00

02 Mar '00

> http://www.radware.com/product/lproof/Default.htm > > I have a customer that requires multihoming and they want to use Linkproof > and I want them to do BGP-4. Does anyone have any experience using this as > an alternative to BGP-4? According to ftp://ftp.vix.com/pub/vixie/ifdefault/, this idea has been around for several years, and does not require any closed-source products. -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

1 0

Forwarded: 47th IETF: ITRACE BOF
by Steven M. Bellovin 02 Mar '00

02 Mar '00

------- Forwarded Message Return-Path: <ietf-123-owner(a)loki.ietf.org> Received: from postal.research.att.com by fetchmail-4.5.7 POP3 for <smb/localhost> (single-drop); Wed, 01 Mar 2000 19:23:02 EST Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA10215 for <smb(a)postal.research.att.com>; Wed, 1 Mar 2000 19:20:12 -0500 (EST) Received: by mail-green.research.att.com (Postfix) id 1F98A1E032; Wed, 1 Mar 2000 19:20:12 -0500 (EST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mail-green.research.att.com (Postfix) with ESMTP id 10D301E036; Wed, 1 Mar 2000 19:20:07 -0500 (EST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id SAA05354 for ietf-123-outbound.01(a)ietf.org; Wed, 1 Mar 2000 18:25:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA05280 for <all-ietf(a)loki.ietf.org>; Wed, 1 Mar 2000 18:13:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16131; Wed, 1 Mar 2000 18:13:04 -0500 (EST) Delivered-To: smb(a)research.att.com Message-Id: <200003012313.SAA16131(a)ietf.org> To: IETF-Announce: ; From: ietf-secretariat(a)ietf.org Cc: new-work(a)ietf.org Subject: 47th IETF: ITRACE BOF Date: Wed, 01 Mar 2000 18:13:03 -0500 Sender: mbeaulie(a)cnri.reston.va.us Content-Type: text X-UIDL: de9f75cb7001aedbabad2854bdf994cd ICMP Traceback BOF (itrace) Thursday, March 30 at 1530-1730 =============================== CHAIR: Steve Bellovin <smb(a)research.att.com> DESCRIPTION: The purpose of the BoF is to look at a mechanism to help address the problem of tracing back denial of service attacks. The suggested mechanism is that with low probability (order 1/20,000), a router seeing a packet would send to the destination an ICMP message giving as much information as it knows about the immediate previous hop of that packet. With enough of these messages -- and if one is being flooded, by definition there will be a lot of traffic, so that the low probabilities will still result in a reasonably complete set of traceback packets. Such a mechanism has other uses as well. It lets people trace down the source of accidentally-emitted bogus packets, i.e., those with RFC1918 addresses. It helps characterize the reverse path, which traceroute does not do. The output will be a standards-track RFC describing the packet format, and the conditions under which it should be sent. Issues include authentication, router load, and host load. AGENDA: Introduction, motivation 15 min Marcus Leech's prototype 20 min Open issues list 30 min Charter 20 min ------- End of Forwarded Message --Steve Bellovin

1 0

~ Work International Business from Home ~
by strategies＠connect4free.net 01 Mar '00

01 Mar '00

1 0