[ih] History of duplicate address tests

[Jack Haverty]

I'm surprised (and disappointed) if this "feature" still exists.

Back in the mid 80s, we created a simple software tool we called a 
"Flakeway".  The purpose was to simulate network problems in order to 
test out a TCP's ability to deal with IP datagrams that were actually 
dropped, reordered, duplicated, or otherwise mangled in transit.  
Computers directly connected to the ARPANET never encountered such 
conditions, so we looked for a way to create them in order to see if a 
TCP implementation really worked.

Such a tool would be most useful if it didn't require changes anywhere 
in the existing equipment.  Ideally it would work by somehow inserting 
itself into the normal path for traffic between two computers 
interacting using TCP, without those computers knowing that it was there.

By exploiting the behavior of ARP and common host implementations that 
Joe mentioned, we created "Flakeway" software.   Typically we would run 
it on a machine with an Ethernet interface that could deal with lots of 
traffic, and which could be put in "promiscuous mode" so that the 
Flakeway would receive all Ethernet traffic regardless of its 
addresses.   The constraint for using the tool was that at least one of 
the computers under test had to be connected to the same Ethernet 
segment, so that all its traffic would be visible at the Flakeway's 
Ethernet interface.  At the time, Sun workstations ("SPARCs") were 
typically available and met the requirements.

Flakeway would start watching all Ethernet traffic (much like Wireshark 
today), and then issue an ARP request for the computer being tested.  On 
receiving the ARP reply, it would immediately send its own ARP reply for 
that same IP address, but specifying itself as the appropriate Ethernet 
target address.  As Joe noted, computers typically flush their address 
caches on seeing new ARP information, and use the most recent response 
for any subsequent traffic they send to that IP address.

After completing this setup, all the interesting traffic now flows to 
the Flakeway machine, which can simply retransmit it to the real 
Ethernet address of the computer being tested.   Other than a slight 
increase in delay, nothing much changes.  By performing the same 
procedure for a (real) gateway's Ethernet address, the Flakeway could 
insert itself into the datagram pathway for traffic in both 
directions.   To do the testing, we then set it up so it could delay, 
duplicate, reorder, discard, and otherwise mangle the IP traffic flow to 
see how the TCPs dealt with such problems (as they were designed to do).

This tool was very useful.  Programming it took only a day or two. But 
it did seem to reveal a vulnerability in the protocols.  E.g., you could 
easily pretend to be any other Internet computer and possibly convince 
some user to enter sensitive information or do other nasty things.

This was all reported, quietly, to IETF, so it could be fixed. 
Meanwhile, it was a useful tool.  About ten years later, in the early 
90s, I tried using the tool again and discovered that it still worked.   
I don't know if that was because the protocols hadn't been improved, or 
because the computers involved weren't up to date.

Curiously, as it became more common to use "switched" Ethernet, the tool 
required more careful configuration of the machines involved to make 
sure the traffic flows were visible to the Flakeway.   Now, with the 
pervasive use of Wifi, and the broadcast nature of radio, maybe the 
pendulum has swung back.

So, a little piece of history of address idiosyncracies.... and use of 
duplicate addresses.

Enjoy,
Jack Haverty


On 11/29/22 12:50, touch--- via Internet-history wrote:
> Hi, Andy,
>
> Using ARP as duplicate address detection has an unintended and possibly dangerous consequence.
>
> If you ARP your own address, you are also broadcasting the IP/Ethernet association of your endpoint as the requesting party. That can flush caches elsewhere and cause traffic to the previous owner of that endpoint to fail - in some cases (and surprisingly) that includes the endpoint that had that address in the first place.
>
> So I don’t think that qualifies as “safe” duplicate address detection and I wouldn’t say that this would be an origin of that concept, as a result.
>
> YMMV.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Nov 29, 2022, at 12:43 PM, Andrew G. Malis via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> John,
>>
>> ARP (RFC 826) trivially enables duplicate IPv4 address detection on
>> Ethernet networks (just ARP for your own address and see if anyone else
>> responds), so I guess November 1982 for IP over Ethernet.
>>
>> Cheers,
>> Andy
>>
>>
>> On Tue, Nov 29, 2022 at 3:23 PM John Kristoff via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>>> My earliest memory, because that is the time of my entry into the
>>> field, of duplicate address detection was done on Token Ring networks
>>> during ring insertion (phase 2 - address verification).  More recently
>>> IPv6 has duplicate address detection (dad).
>>>
>>> I'm curious to know about the earliest of duplicate address detection
>>> mechanisms.  I imagine there were some predating what I remember about
>>> Token Ring, but this is the kind of thing that is difficult to uncover
>>> without some hints. Any pointers to the earliest of these functions in
>>> networking?
>>>
>>> Thanks kindly,
>>>
>>> John
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history