[ih] History question -- multi-homing

[Jack Haverty]

Hi Karl,

Yes, I also ran into LU6.2 when I joined Oracle in 1990.  Our software 
had to run over any kind of network a customer might have, and LU6.2 was 
certainly one of them.  We even supported Banyan Vines and probably some 
other obscure technologies that I've forgotten.  All our software 
required from any network was some kind of virtual-circuit service, and 
every network technology had something that could be used for clients 
and servers to talk to each other. Lots of different but surprisingly 
similar protocols and formats, all trying to convince the market that 
their choice was the right one.   Until TCP won those protocol wars.

IIRC, the "Flakeway" was created at BBN in the early 1980s.   I think it 
was one of the "system engineers" in my group (Dan Wood IIRC) who 
noticed the possibility of using the ARP mechanism to hijack a stream of 
IP datagrams.  Jon Postel was on the ICCB and he probably first heard 
about Flakeway when I told the ICCB about it and the use of End-Middle 
scenarios to build such a tool.

There's a lot of discussion today about the imminent ability of some AI 
to "take over the Internet".  That kind of "hacking" was foreseen in the 
early 1980s as a possibility, given the numerous issues associated with 
"End-Middle" interactions at many protocol levels. It enabled the 
construction of very useful diagnostic and debugging tools.

I wonder how many of such issues have been addressed since then.  AI and 
their massive datacenters will probably find such issues far faster than 
human engineers have.

/Jack Haverty

On 9/15/26 14:29, Karl Auerbach wrote:
> On 9/15/26 12:10 AM, Jack Haverty via Internet-history wrote:
>
>> Re: the question of when these issues first surfaced...here's what I 
>> remember:
>>
>> POLICY ROUTING
>
> Back in the '80's I worked a bit with ... I hope you are sitting down 
> ... IBM's SNA LU6.2.  It was very much in line with traffic engineered 
> paths such as MPLS and ATM in which paths were centrally computed and 
> then disseminated to the routing nodes. (SNA also did a lot of 
> protocol conversions in the path, so often that pre-computed path 
> focused on a protocol-conversion site somewhere in the middle.)
>
> I called this kind of path-nailing "Yenta Networking" after the 
> legendary role of a matchmaking Yenta.  (I do believe that this kind 
> of arranged client-server binding does have a place on today's net.  
> My memory is also saying to me, in the voice of Dave Bridgham, "don't 
> forget the Nimrod proposals" which used IP source routing.)
>
> ===
>
>> In the early 1980s Internet, we used such end-middle traffic to 
>> create a diagnostic tool called a "Flakeway".
>
> In the last couple of decades I have extrapolated from Jon's 
> "flakeway" concept.  I've moved it down a layer, so that it lives down 
> at the Ethernet layer, essentially an Ethernet bridge (that does not 
> participate in things like Spanning Tree, and forwards some of the 
> mysterious frames defined by IEEE such as "Pause".)  (I've also added 
> a lot of frame/packet classification so that different kinds of 
> traffic can be run through different sequences of "bad things".)
>
> I experimented with digging into packets and changing the contents - I 
> demonstrated some of this at an Interop show a couple of decades ago, 
> in the Interop Labs, where I injected words in to VOIP sessions (on 
> the RTP protocol.)
>
> But that kind of active perturbation of content was hard to do on fast 
> links.  (A modern 10G or higher link can move a lot of frames a second 
> - in both directions.)  So we moved that into a different test tool.  
>  (And we did generalize it to do "fun things" such as a thing we 
> called a "constipation engine" - a device to plop in front of busy web 
> servers that were being hit with bogus traffic. The device would slow 
> the packets from the server, sometimes splitting them, and managing 
> the TCP window, so that the attacker would perceive that the 
> connection was open and working, but it was very, very, very slow.  
> Attackers who were simply running scripts, aka "script kiddies", would 
> perhaps not notice that attack scripts that once took seconds now took 
> hours.)
>
> So in my later stuff I've most dropped back to what I call "basic 
> impairments" - latency (fixed and variable), duplication, drop, packet 
> re-sequencing, rate limitation.  (All of these have umpteen control 
> knobs to vary what is being done, such as statistical distributions of 
> variable delay, and change things over time [like changing packet drop 
> to emulate a low earth satellite as it rises from the horizon, crosses 
> overhead, and descends.)  (I still have older code that can change 
> packet contents.)
>
> My latest implementation does the heavy lifting down in the FreeBSD 
> kernel, so it can achieve reasonable packet (actually "frame") rates.  
> (And doing this stuff can require some heavy lifting from multiple 
> processor cores and use a lot of non-pageable, locked-down memory - 
> simulating things like earth-to-JWST-delays (more than ten seconds, 
> one way), especially if we add latency variation and allow packet 
> re-ordering, can burn a lot of memory for a 10G link.)
>
> These have been rather useful tools for developers.  These tools push 
> protocol implementations into realms that are not typically found in 
> developer lab networks or even the Internet on a good day.
>
> We've pushed a lot of IP stacks over the edge, even the Linux one (it 
> can run out of memory for packet reassembly if subjected to some of 
> the more perverse patterns of IPv4 fragmentation over a period of 
> time.)  We've also made some people unhappy - like a phone vendor who 
> had hundreds of thousands of phones out that that collapsed when we 
> ran some tests of infrequent but legitimate traffic patterns against 
> them.  And I remember at one SIPit event I was able to push nearly 
> every implementation into the danger zone simply by collecting packets 
> into a "dam" for maybe a 0.2 seconds then let that "dam burst" but 
> releasing the packets in an order different than arrival.  I also 
> remember one very large vendor of servers in which we found that their 
> TCP stack properly did congestive back-off, but failed to climb back 
> to speed afterwords.
>
> (My favorite one is to re-frame an IP packet into an Ethernet frame 
> that is larger than necessary.  A lot of stacks use the Ethernet 
> length rather than the IP length and thus end up running into the 
> unknown data in that slop space between the end of the IP packet and 
> the end of the Ethernet frame.)
>
>         --karl--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260915/f79dcf08/attachment.asc>