[ih] History of duplicate address tests

[Grant Taylor]

On 11/29/22 2:51 PM, Jack Haverty via Internet-history wrote:
> I'm surprised (and disappointed) if this "feature" still exists.

Well, I think you should be surprised and disappointed as this feature 
seems to still be very much a thing.

> 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.

Interesting.

As I read your message I was wondering how many of those things could be 
implemented with a properly configured Linux kernel / system.  Dropped, 
delayed, and mangled can probably easily be done with firewalling and / 
or QoS features.

Reordering might be somewhat more problematic and require changing the 
path that frames / packets take through the network such that one path 
has a delay.  Thus you send some frames / packets through the delay and 
others more direct thereby inducing an out of order condition.

Duplication is a tough nut to crack.  Or at least I'm not aware how to 
go about doing that with firewalling and / or QoS.  There might be a way 
to punt the frame / packet to user space where a daemon would duplicate 
it and re-inject it into the network.

> 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.

The more that I learn about the ARPANET and NCP the more impressed I am.

I also see why you needed to test TCP stacks against new problems that 
didn't exist in the ARPANET.

> 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.

I see two older methods and one newer method to do this.  The first 
older method is effectively monkeying with the ARP cache like Flakeaway 
did.  Many grey / black hat tools still do this.  The second method is 
to get in path / route between source and destination ostensibly on 
different subnets passing through a router.  The third, newer, method is 
to leverage something like SDN / OpenFlow to receive a frame / packet, 
ship it off to a controller to fold, spindle, or mutilate it before 
sending it back to the egress device.

> By exploiting the behavior of ARP and common host implementations that 
> Joe mentioned, we created "Flakeway" software.

I instantly knew /how/ you did -- what I'll call -- the /interception/ 
bit based on the description.  I say this because I know how this works 
from contemporary network problems / vulnerabilities that -- to the best 
of my knowledge -- still exist at the end of 2022.

Does the name / phrase "Firesheep" mean anything to you?

According to Wikipedia, Firesheep came out in late 2010.  Firesheep was 
targeted at WiFi networks which were inherently broadcast.  But my 
understanding is that it was possible to make it work on traditional 
LANs, even switched LANs, via ARP techniques that you and Joe referred 
to, specifically the LAN's default gateway.

> 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.

Needing to be on the same network segment as the source and / or 
destination means that you were completely playing at layer 2.

Newer tools allow attacking systems on different network segments as 
long as you are in the routed path between said systems.  E.g.

[A]---(1)---[B]---(2)---[C]

B can run contemporary counterparts to Flakeway which would target R1 & 
R2's L2 MAC addresses and selectively target A's & C's L3 IP address.  }:-)

> 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.

*nod*nod*

> 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.

I would think that the computers would /update/ their ARP cache for the 
IP to MAC mapping for the specific victim and not actually /flush/ all 
of the ARP cache.

> 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.

Yep.  That's how things still work today.

> Other than a slight increase in delay, nothing much changes.

Agreed.

Really, the only way for clients on the same LAN to have any idea that 
this is happening is to check the MAC address that each has associated 
with the other's IP address.

Incidentally, this is why it's a good idea to check the ARP cache when 
weird things are happening.  Make sure that each machine has the correct 
MAC address for the other machine.

> 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).

That makes perfect sense to me.

> This tool was very useful.

Today, Flakeway would be considered a grey hat hacking tool.  Just one 
of may that fall into the category.

> Programming it took only a day or two. But it did seem to reveal a 
> vulnerability in the protocols.
This vulnerability sill very much so exists today.

The vast majority of people assume ~> believe that the L2 LAN broadcast 
domain is a safe place.  That's is a VERY dangerous assumption.  I'd say 
that greater than 95% of the time it is safe.  But when it's not safe, 
it's really not safe.

> 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.

Yep.

> This was all reported, quietly, to IETF, so it could be fixed.

Chuckle.

Based on the following comment, I'm guessing this was reported in the 
early '80s, correct?

> Meanwhile, it was a useful tool.

I'll argue that it still is a useful tool.  At least to some people.

> About ten years later, in the early 90s, I tried using the tool again 
> and discovered that it still worked.

I'd bet a lunch that it still would work in many situations in late 2022.

> I don't know if that was because the protocols hadn't been improved, 
> or because the computers involved weren't up to date.

I suspect it's more the former, the protocols hadn't been improved.

Stop and think for a moment, what has changed in networking protocols 
since the time you were messing with them?  Not much.  Most of the 
changes happened at higher layers that still depend on the protocols 
that operate at the lower layers that you're talking about.

> 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.

Ya.  With switches, you either MUST use ARP techniques /or/ you need to 
continually flood the switch and bust it down to a hub.

Promiscuous mode doesn't mean nearly as much as it used to.  It used to 
mean everything on / passing through the LAN segment.  Now it only means 
everything on the host.  Different implementations will see different 
types of traffic, direct or direct + broadcast.

> Now, with the pervasive use of Wifi, and the broadcast nature of radio, 
> maybe the pendulum has swung back.

The pendulum never really swung completely away.  But yes, older WiFi 
very much so did swing it back.

I say older WiFi, as in not fairly new WiFi.  This is because fairly new 
(maybe just before contemporary) WiFi was going to start using different 
encryption between each client and the AP.  Thus clients couldn't 
decrypt RF broadcasted traffic that was unicast IP traffic to another 
machine on the LAN.

According to Wikipedia, IPsec pre-dates SSL.  IPsec being early '90s and 
SSL being mid to late '90s.  Then in the late 2000s MACsec started to 
become a thing.

Both IPsec and SSL move the authentication / integrity / confidentiality 
higher up the stack than the layer 2 ARP attacks being discussed. 
MACsec is the first thing that I'm aware of that actually addresses the 
crux of the layer 2 ARP attack.

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

It is history.  But I think the underlying layer 2 ARP problem is still 
very much with us today in late 2022.

I was recently listening to the episode 27 of APNIC's PING podcast -- 
Wither RPKI -- wherein one of the hosts mentioned that people have 
tended to prefer to address the authentication / integrity / 
confidentiality at the top layer of the OSI stack as this tends to work 
across more things in an end to end manner.  MACsec is L2 and inherently 
local to the broadcast domain.  IPsec is L3 but is limited to IP 
addresses.  Whereas TLS is L7 and can actually ride across multiple 
underlying transports, not all of which involve IP.  What's more is that 
it's relatively easy to co-mingle multiple TLS (L7) endpoints on a 
single IP address via things like (e)SNI.

Some later parts of the podcast even went so far as to say that IP 
addresses aren't important any more.  Their justification is that with 
things like (e)SNI and CDNs, IP addresses aren't as important as they 
once were.  --  I've got to say, the comments make some sense.  Not that 
I like what they are saying.



-- 
Grant. . . .
unix || die