[ih] History of duplicate address tests

[Jack Haverty]

Hi Grant,

Thanks for the update.  I remember reporting the issue to IETF back in 
the mid 80s and again in the early 90s.   I guess it still hasn't risen 
to the top of anybody's priority list.

FYI, Flakeway was a user-level program that ran on a Sparc.   We didn't 
have access to the Sun kernel code so it didn't involve any kernel 
mods.  Essentially the Flakeway was a simplified clone of a regular 
gateway, with the features added for mangling the datagram stream.  
Doing everything at user level made the programming much easier, and 
worked fine for a debugging tool.

Also FYI, there was a similar mechanism we put into the IMPs, called a 
"Remote Datascope".  This took advantage of some ancient code that was 
originally put in the IMP to gather data for the UCLA measurement work 
on the neonatal ARPANET.  The Datascope simply told the IMP to copy the 
first N bytes of every packet (filtered to only those of interest) 
transiting the IMP, and send that data in a separate packet to the 
Datascope address.   This allowed us to "hang a datascope" on a network 
connection and view computer-computer interactions from somewhere else. 
No probe hanging on to a wire needed.  By setting the "N" value large 
enough we could capture TCP and IP headers.   This proved very useful in 
debugging problems as hosts were trying to convert to the DDN and get 
TCP running.   I don't recall if we ever put similar functionality into 
the "core gateways", since they were all connected to some IMP, but it 
would have been easy to do so.

One of the other related but larger issues on the 80s list of "things we 
need to do" was something I called the "end-middle" scenario.  It's a 
generalization of the ARP issue that Flakeway exploited.

The basic notion is that if you look at a chunk of data passing through 
the network, at any level of protocol, it contains a lot of pieces of 
information other than the actual user data, such as the various fields 
in the different headers at different layers.

There was a lot of interest in the early days in end-to-end mechanisms, 
which eventually led to things like SSL, PGP, et al. The "end-middle" 
scenario broadened that view of the Internet architecture.

Basically, each such "chunk" of data in any header in any protocol level 
is produced somewhere, and consumed somewhere else, possibly in multiple 
places.  So a "consumer" of some piece of data typically needs to have 
some mechanism for assurance that the piece of data was actually 
produced by who you think produced it, and has not been altered or 
mangled ("Flaked?") along the way to the consumer.

Essentially, there are a lot more "ends" involved in Internet 
communication than most people think.   Many of the "ends" are actually 
somewhere in the "middle".

So, for example, in the context of the IP header, when some box along 
the path receives an IP datagram, the IP source address should be 
assured to be the actual source address of the computer you think it 
is.  Similarly, an ARP message conveying an address mapping should be 
assured to have come from a source that is authorized to report such 
information.

Every field, of every header, that is being used to make programming 
decisions, no matter where it is produced or consumed, potentially needs 
to be protected to assure its authenticity.

The "end-middle" issue appears at all levels of protocols. Violating it 
at level 2 made Flakeway possible.  But the issue exists even at "app" 
levels -- e.g., all the "header fields" that you see today in email.   
IIRC, a similar violation made NAT possible.

We recognized in the 80s that such protection mechanisms would be 
difficult, and consume a lot of computing power that we didn't have, and 
require protocols and mechanisms that did not yet exist.   Also, they 
weren't really needed for an experimental research network, as long as 
the architecture permitted them to be added later for operational use.

So the "end-middle issue" was on the list of "things we need to do".

I guess it's still there.

Jack



On 11/30/22 18:40, Grant Taylor via Internet-history wrote:
> 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.
>
>
>