From mbaer at cs.tu-berlin.de Thu Aug 5 15:40:50 2010 From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=) Date: Fri, 06 Aug 2010 00:40:50 +0200 Subject: [ih] Source routing, IEN 80, and IEN 95 Message-ID: <4C5B3DF2.6070405@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone out there. I am wondering (mainly just out of curiosity) about the implementation and usage record of source routing in the early Internet. The IPv4 spec (starting with IEN 80) came to include it eventually, but my impression is that while people *thought* it would be important, in reality no one cared too much and it wasn't used much. My question: have people actually been using it for purposes other than spoofing attacks? What about routing debugging? And, load balancing? Plus, how widespread did it become in gateways/routers before security concerns rendered it a complete no-go? Thanks for your recounts and takes. - -- Matthias B?rwolff www.b?rwolff.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWz3eAAoJEFEeq050tDy5c5oH/iY4z3C/frHh8dzazEqU/el5 5fWPzHveC+PyZpfGRHvq+EehGgfRL9n5ZJA7YgqMM5Lyxs2ZZm8nqSbyTaZ9RIj/ cGnPABlmHS7d70iGGZRUsZg4afpyM2/7k2OmpultBWsfJ63OIkb+N0J+2GvmRfDx VSrI1pMgIyek/m/XXElrwmxvt/pKcrPpY0i26E4hmz1EeXifhZ2lC87BNw7l6rcN 6Fu6gEMkkUtHVw6XEiddx4Zzz58gjz97A4x8qBcJFnaAVk7UgaK7odIQPoQteg+h vLrl52iAZoQq5YUIUP7IGFHxJfY5Gd/E6IE/dDJSSpGQyfAJ97hueiqEO/4qZKY= =FSY4 -----END PGP SIGNATURE----- From jeanjour at comcast.net Thu Aug 5 16:10:39 2010 From: jeanjour at comcast.net (John Day) Date: Thu, 5 Aug 2010 19:10:39 -0400 Subject: [ih] Source routing, IEN 80, and IEN 95 In-Reply-To: <4C5B3DF2.6070405@cs.tu-berlin.de> References: <4C5B3DF2.6070405@cs.tu-berlin.de> Message-ID: Source routing is a male thing - the packets don't want to stop and ask for directions. ;-) Sorry, couldn't resist. At 0:40 +0200 2010/08/06, Matthias B?rwolff wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi everyone out there. I am wondering (mainly just out of curiosity) >about the implementation and usage record of source routing in the early >Internet. The IPv4 spec (starting with IEN 80) came to include it >eventually, but my impression is that while people *thought* it would be >important, in reality no one cared too much and it wasn't used much. > >My question: have people actually been using it for purposes other than >spoofing attacks? What about routing debugging? And, load balancing? > >Plus, how widespread did it become in gateways/routers before security >concerns rendered it a complete no-go? > >Thanks for your recounts and takes. > >- -- >Matthias B?rwolff >www.b?rwolff.de >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJMWz3eAAoJEFEeq050tDy5c5oH/iY4z3C/frHh8dzazEqU/el5 >5fWPzHveC+PyZpfGRHvq+EehGgfRL9n5ZJA7YgqMM5Lyxs2ZZm8nqSbyTaZ9RIj/ >cGnPABlmHS7d70iGGZRUsZg4afpyM2/7k2OmpultBWsfJ63OIkb+N0J+2GvmRfDx >VSrI1pMgIyek/m/XXElrwmxvt/pKcrPpY0i26E4hmz1EeXifhZ2lC87BNw7l6rcN >6Fu6gEMkkUtHVw6XEiddx4Zzz58gjz97A4x8qBcJFnaAVk7UgaK7odIQPoQteg+h >vLrl52iAZoQq5YUIUP7IGFHxJfY5Gd/E6IE/dDJSSpGQyfAJ97hueiqEO/4qZKY= >=FSY4 >-----END PGP SIGNATURE----- From richard at bennett.com Thu Aug 5 17:06:12 2010 From: richard at bennett.com (Richard Bennett) Date: Thu, 05 Aug 2010 17:06:12 -0700 Subject: [ih] Source routing, IEN 80, and IEN 95 In-Reply-To: References: <4C5B3DF2.6070405@cs.tu-berlin.de> Message-ID: <4C5B51F4.8060204@bennett.com> An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Thu Aug 5 17:54:39 2010 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 05 Aug 2010 20:54:39 -0400 Subject: [ih] Source routing, IEN 80, and IEN 95 In-Reply-To: <4C5B51F4.8060204@bennett.com> References: <4C5B3DF2.6070405@cs.tu-berlin.de> <4C5B51F4.8060204@bennett.com> Message-ID: <4C5B5D4F.8030606@meetinghouse.net> At 0:40 +0200 2010/08/06, Matthias B?rwolff wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi everyone out there. I am wondering (mainly just out of curiosity) >>> about the implementation and usage record of source routing in the >>> early >>> Internet. The IPv4 spec (starting with IEN 80) came to include it >>> eventually, but my impression is that while people *thought* it >>> would be >>> important, in reality no one cared too much and it wasn't used much. >>> >>> My question: have people actually been using it for purposes other than >>> spoofing attacks? What about routing debugging? And, load balancing? Your question sparked my curiousity, so I did a little digging. As I recall, from a long time back, there was a collection of work on routing that involved "route servers" and source routing - instead of relying on routers to maintain routing information, a protocol stack would request a route from a route server, and then use source routing to send packets along that route. More recently, it looks like source routing is being used in some of the experimental routing models applied in MANETs (mobile ad hoc networks) - for example DSR (Dynamic Source Routing), http://tools.ietf.org/html/rfc4728 - the basic model is that nodes do "route discovery," to find paths to other nodes, and then use source routing to push packets along those routes. There's a pretty good list of various MANET protocols on Wikipedia, at http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list I haven't dug further, but I expect that source routing becomes a lot more secure if you add some cryptographic authentication into the mix. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Thu Aug 5 18:22:18 2010 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 05 Aug 2010 21:22:18 -0400 Subject: [ih] Source routing, IEN 80, and IEN 95 In-Reply-To: <4C5B5D4F.8030606@meetinghouse.net> References: <4C5B3DF2.6070405@cs.tu-berlin.de> <4C5B51F4.8060204@bennett.com> <4C5B5D4F.8030606@meetinghouse.net> Message-ID: <4C5B63CA.2050803@meetinghouse.net> Miles Fidelman wrote: > At 0:40 +0200 2010/08/06, Matthias B?rwolff wrote: >>>> My question: have people actually been using it for purposes other >>>> than >>>> spoofing attacks? What about routing debugging? And, load balancing? > > More recently, it looks like source routing is being used in some of > the experimental routing models applied in MANETs (mobile ad hoc > networks) - for example DSR (Dynamic Source Routing), > http://tools.ietf.org/html/rfc4728 - the basic model is that nodes do > "route discovery," to find paths to other nodes, and then use source > routing to push packets along those routes. There's a pretty good > list of various MANET protocols on Wikipedia, at > http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list > > I haven't dug further, but I expect that source routing becomes a lot > more secure if you add some cryptographic authentication into the mix. Well, it turns out that there is quite a bit about combining source routing with encryption in a MANET context - if you're interested, try googling: "source routing" MANET encryption or secure DSR Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From brescia74 at verizon.net Thu Aug 5 18:25:23 2010 From: brescia74 at verizon.net (Mike Brescia) Date: Thu, 05 Aug 2010 21:25:23 -0400 Subject: [ih] Source routing, IEN 80, and IEN 95 (in use) In-Reply-To: References: <4C5B3DF2.6070405@cs.tu-berlin.de> Message-ID: <18E749ED-B688-4D90-87CE-D36F6DCC6887@verizon.net> John, You got it exactly right. You cannot "stop and ask for directions" from normal routing when something may have broken it. In the early days of SATNET (1978..), when the routing or the SATNET or ARPANET network infrastructure failed between the U.S. either the U.K. or Europe, fallback source routes configured in the monitoring and control program were used to get around the failure. On ARPANET and SATNET, failure of one of the satellite links would isolate parts of one net and a set of configured source-routes via other nets would be tried as the way to reach nodes which were not normally responding, bypassing the break. The only programs I saw using this approach was the IMP monitor/control program NU and before that, U. Oh, and later, monitoring for the "Wideband" net also at BBN. While a user tool (e.g. telnet, ftp) may have had a source-route command line option to force a bypass in extreme cases, I cannot recall those tools having a configuration file setup for trying fallback routes. network example: (forgive the ASCII "art") NOC ..2................> | ARPANET(10) . +-------+=========+-------+ ..1.. | | . . R1 R2 . . | | . v + + v \ / SATNET(4) XXXXX / \ + + NOC = network ops center + = network node (IMP, SATNET IMP) === = ARPANET satellite link R = gateway(router) XXX = break in SATNET isolating parts of net 4 .1. = normal path to net 4 via R1 .2. = source-routed path to isolated part of net 4 via R2 -- Mike Brescia (BBN &seq. '78-'02) On Aug 5, 2010, at 7:10 PM, John Day wrote: > Source routing is a male thing - the packets don't want to stop and ask for directions. > > ;-) Sorry, couldn't resist. > > > At 0:40 +0200 2010/08/06, Matthias B?rwolff wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi everyone out there. I am wondering (mainly just out of curiosity) >> about the implementation and usage record of source routing in the early >> Internet. The IPv4 spec (starting with IEN 80) came to include it >> eventually, but my impression is that while people *thought* it would be >> important, in reality no one cared too much and it wasn't used much. >> >> My question: have people actually been using it for purposes other than >> spoofing attacks? What about routing debugging? And, load balancing? >> >> Plus, how widespread did it become in gateways/routers before security >> concerns rendered it a complete no-go? >> >> Thanks for your recounts and takes. >> >> - -- >> Matthias B?rwolff >> www.b?rwolff.de >> ----- elided PGP SIGNATURE----- From odlyzko at umn.edu Fri Aug 6 07:55:17 2010 From: odlyzko at umn.edu (Andrew Odlyzko) Date: Fri, 06 Aug 2010 09:55:17 -0500 Subject: [ih] question about Internet traffic growth rates during the bubble years Message-ID: <4c5c2255.MeTz1YIeeS4CiKmY%odlyzko@umn.edu> Enclosed below is an announcement of a paper on technology bubbles. It is based largely on the Internet bubble of a decade ago, and concentrates on the "Internet traffic doubling every 100 days" tale. As the paper shows, this myth was perceived in very different ways by different people, and this by itself helps undermine the foundations of much of modern economics and economic policy making. To get a better understanding of the dynamics of that bubble, to assist in the preparation of a book about that incident, I am soliciting information from anyone who was active in telecom during that period. I would particularly like to know what you and your colleagues estimated Internet traffic growth to be, and what your reaction was to the O'Dell/Sidgmore/WorldCom/UUNet myth. If you were involved in the industry, and never heard of it, that would be extremely useful to know, too. Ideally, I would like concrete information, backed up by dates, and possibly even emails, and a permission to quote this information. However, I will settle for more informal comments, and promise confidentiality to anyone who requests it. Andrew Odlyzko odlyzko at umn.edu http://www.dtc.umn.edu/~odlyzko/doc/mania03.pdf Bubbles, gullibility, and other challenges for economics, psychology, sociology, and information sciences Andrew Odlyzko School of Mathematics and Digital Technology Center University of Minnesota odlyzko at umn.edu http://www.dtc.umn.edu/~odlyzko Preliminary version, August 5, 2010 ABSTRACT Gullibility is the principal cause of bubbles. Investors and the general public get snared by a "beautiful illusion" and throw caution to the wind. Attempts to identify and control bubbles are complicated by the fact that the authorities who might naturally be expected to take action have often (especially in recent years) been among the most gullible, and were cheerleaders for the exuberant behavior. Hence what is needed is an objective measure of gullibility. This paper argues that it should be possible to develop such a measure. Examples demonstrate, contrary to the efficient market dogma, that in some manias, even top-level business and technology leaders do fall prey to collective hallucinations and become irrational in objective terms. During the Internet bubble, for example, large classes of them first became unable to comprehend compound interest, and then lost even the ability to do simple arithmetic, to the point of not being able to distinguish 2 from 10. This phenomenon, together with advances in analysis of social networks and related areas, points to possible ways to develop objective and quantitative tools for measuring gullibility and other aspects of human behavior implicated in bubbles. It cannot be expected to infallibly detect all destructive bubbles, and may trigger false alarms, but it ought to alert observers to periods where collective investment behavior is becoming irrational. The proposed gullibility index might help in developing realistic economic models. It should also assist in illuminating and guiding decision making. ----------------------------------------------------------------------------- If you would like to be on the mailing list for notifications of future papers on technology bubbles, please send me a note at odlyzko at umn.edu The previous three papers in this series are available at: 1. Collective hallucinations and inefficient markets: The British Railway Mania of the 1840s http://www.dtc.umn.edu/~odlyzko/doc/hallucinations.pdf 2. This time is different: An example of a giant, wildly speculative, and successful investment mania, B.E. Journal of Economic Analysis & Policy, vol. 10, issue 1, 2010, article 60 (registration required) http://www.bepress.com/bejeap/vol10/iss1/art60 preprint available at: http://www.dtc.umn.edu/~odlyzko/doc/mania01.pdf 3. The collapse of the Railway Mania, the development of capital markets, and Robert Lucas Nash, a forgotten pioneer of accounting and financial analysis http://www.dtc.umn.edu/~odlyzko/doc/mania02.pdf ----------------------------------------------------------------------------- Source materials for the Railway Mania and the Internet bubble are available at the web pages http://www.dtc.umn.edu/~odlyzko/rrsources/ and http://www.dtc.umn.edu/~odlyzko/isources/ From jack at 3kitty.org Fri Aug 6 10:43:51 2010 From: jack at 3kitty.org (jfh) Date: Fri, 06 Aug 2010 10:43:51 -0700 Subject: [ih] Source routing, IEN 80, and IEN 95 (in use) In-Reply-To: <18E749ED-B688-4D90-87CE-D36F6DCC6887@verizon.net> References: <4C5B3DF2.6070405@cs.tu-berlin.de> <18E749ED-B688-4D90-87CE-D36F6DCC6887@verizon.net> Message-ID: <1281116631.31795.61.camel@localhost> Hi Mike! I was going to reply to Matthias' message by saying that the best source would be someone who actually wrote the code - like Mike Brescia. TWIMC, Mike was the guy who had the interesting job of keeping the "core internet" running back in the late 70s/early 80s timeframe. So his comments about the use of source routing as a debugging tool can be taken as gospel. We had had a lot of experience from operating the ARPANet at BBN, and so the idiosyncracies of routing algorithms were well known, especially their tendencies to behave in unexpected ways. So tools were very important in that experimental period, and that need motivated the implementation of source routing, traceroute, SNMP, TCP ports like sources and sinks, etc. As I recall, there were a bunch of other motivations for source routing. Remember, it was a very experimental time - the whole Internet was officially an experiment. At the "IP level" there were quite a few projects which were also building gateways/routers, which were typically (at that time) attached as "branches" hanging off the core. Source routing in the core allowed people to force packets to go a certain way, so that they would go into the appropriate "other internet" rather than taking what might be a more direct route through the normal core routes. I think Dave Mills used this in some of his work. Also, people were experimenting with things like packet voice. The core routing scheme was pretty simple, based purely on hops, with no concern for delay, available bandwidth, cost, etc. The Wideband Net was roughly parallel to the core internet system, and had much higher bandwidth (but of course much higher delay, being satellite based). So it was desirable to route non-interactive packet voice/video through the WBNet, e.g., between east and west coast US. But with normal core internet routing, packets arriving into the core from a site on the east coast would be sent directly to the site on the west coast through low-speed terrestrial circuits - when it would be preferable to "detour" them to the high-speed east coast satellite connection, across the satellite, and back into the core on the west coast. The "shortest hop" route was not the right answer. The normal core routing would never choose a longer route (unless the core internet was partitioned, making the satellite route shorter). So source routing was a way to get packets to go the way you wanted. This particular scenario was called "Expressway Routing". There were a handful of such "not yet solved issues" that Jon Postel used to write on the board at every ICCB/IAB/TCPIPWG meeting. E.G., the "VAN gateway" (connected ARPANet with Telenet (sic)) enabled the use of the public X.25 network to get packets from the US to UK. SATNET could also provide that transatlantic connection. However, SATNET was only to be used for research projects that funded it. Conversely, the X.25 net was open for anyone - but it cost real money - for each packet - to use it, which came out of DARPA's budget. So there was a desire to make sure that various projects sent their traffic through the appropriate paths, which source routing could help accomplish. An interesting quirk was that the X.25 costs were charged to the end which opened the X.25 connection. If the UK end opened the connection, the UK got the bill, and converse for US. This asymmetry motivated some interesting algorithms in the VAN gateway thinking - implementing the old Manager's Mantra "Move your expenses into someone else's budget". AFAIK, this was the beginning of the "Policy Routing" issue. The "grand scheme" was that all of these scenarios would be explored by experimentation, and then the lessons learned would be used to design and implement a routing protocol which handled everyone's needs - the Grand Unified Routing Protocol, aka GURP (don't google that, I just made it up). Not an easy task. I don't think there was ever an intent that source routing be used as an end-user tool. After the experimentation phase ended and the "real" routing mechanism was in place, source route et al would be simply internal tools for network management and operations (like ping, traceroute, etc.). In effect, there would be multiple, possibly many, independent routing algorithms running on the same physical Internet, each concerned with figuring out the "least cost" path for packet flow based on independent criteria about what "cost" meant - actual money, lowest delay, achievable throughput, available unused capacity, ownership of circuits, time of day, etc. For any given packet, the TOS (type of service) field would be used to select which routing service to use for that packet. This would also permit the operation of independent congruent internets with different behaviors. E.G., the "premium" network would route packets with little regard for cost. The "bulk cargo" internet would route packets only through paths that would otherwise be idle. No one at the time cared much about pricing policies, but premium service would obviously be more valuable than bulk. You'll have to ask someone else how far today's Internet has gotten in terms of that 80s-era grand scheme. That was about the time that routers started popping up like dandelions all over the place and I think we lost control of the experiment. I get this sense of deja vu when I read today about the "net neutrality" debates. It seems to me like a new name for the same problem from that 80s white-board list. Hope this helps, /Jack Point Arena, CA On Thu, 2010-08-05 at 21:25 -0400, Mike Brescia wrote: > John, > > You got it exactly right. You cannot "stop and ask for directions" from normal routing when something may have broken it. > > In the early days of SATNET (1978..), when the routing or the SATNET or ARPANET network infrastructure failed between the U.S. either the U.K. or Europe, fallback source routes configured in the monitoring and control program were used to get around the failure. On ARPANET and SATNET, failure of one of the satellite links would isolate parts of one net and a set of configured source-routes via other nets would be tried as the way to reach nodes which were not normally responding, bypassing the break. The only programs I saw using this approach was the IMP monitor/control program NU and before that, U. Oh, and later, monitoring for the "Wideband" net also at BBN. > > While a user tool (e.g. telnet, ftp) may have had a source-route command line option to force a bypass in extreme cases, I cannot recall those tools having a configuration file setup for trying fallback routes. > > network example: (forgive the ASCII "art") > > NOC ..2................> > | ARPANET(10) . > +-------+=========+-------+ > ..1.. | | . > . R1 R2 . > . | | . > v + + v > \ / > SATNET(4) XXXXX > / \ > + + > > NOC = network ops center > + = network node (IMP, SATNET IMP) > === = ARPANET satellite link > R = gateway(router) > XXX = break in SATNET isolating parts of net 4 > .1. = normal path to net 4 via R1 > .2. = source-routed path to isolated part of net 4 via R2 > > > -- Mike Brescia (BBN &seq. '78-'02) > > > On Aug 5, 2010, at 7:10 PM, John Day wrote: > > Source routing is a male thing - the packets don't want to stop and ask for directions. > > > > ;-) Sorry, couldn't resist. > > > > > > At 0:40 +0200 2010/08/06, Matthias B?rwolff wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi everyone out there. I am wondering (mainly just out of curiosity) > >> about the implementation and usage record of source routing in the early > >> Internet. The IPv4 spec (starting with IEN 80) came to include it > >> eventually, but my impression is that while people *thought* it would be > >> important, in reality no one cared too much and it wasn't used much. > >> > >> My question: have people actually been using it for purposes other than > >> spoofing attacks? What about routing debugging? And, load balancing? > >> > >> Plus, how widespread did it become in gateways/routers before security > >> concerns rendered it a complete no-go? > >> > >> Thanks for your recounts and takes. > >> > >> - -- > >> Matthias B?rwolff > >> www.b?rwolff.de > >> ----- elided PGP SIGNATURE----- > > From jack at 3kitty.org Fri Aug 6 11:31:26 2010 From: jack at 3kitty.org (jfh) Date: Fri, 06 Aug 2010 11:31:26 -0700 Subject: [ih] Source routing, IEN 80, and IEN 95 (in use) In-Reply-To: <1281116631.31795.61.camel@localhost> References: <4C5B3DF2.6070405@cs.tu-berlin.de> <18E749ED-B688-4D90-87CE-D36F6DCC6887@verizon.net> <1281116631.31795.61.camel@localhost> Message-ID: <1281119486.31795.72.camel@localhost> > but my impression is that while people *thought* it would be > > >> important, in reality no one cared too much and it wasn't used > much. One other comment: Since Source Routing involved using an IP option field, packets that were source-routed necessarily got bigger. Also, there was a tendency for people to try to put as much data in a packet as possible, since one of the limitations of the routers (and hosts) at that time was the number of packets per second that could be processed. When an already-full packet got bigger because of source-routing, the packet was much more likely to be fragmented somewhere, which pretty much everyone agreed was a Very Bad Thing, causing all sorts of problems and to be avoided at all costs. It also could seriously change the behavior of the packet as it went through the system, which would make any kind of performance measurement data possibly useless. So, I think people might have cared about getting the desired behavior from source routing, but the undesirable side-effects may have made them abandon the use of it. The best people to ask would be the packet voice crowd from the 80s, e.g., the SRI and ISI groups. /Jack