[ih] History of duplicate address tests

[Grant Taylor]

On 12/1/22 11:03 AM, Jack Haverty via Internet-history wrote:
> Hi Grant,

Hi Jack,

> Thanks for the update.

You're welcome.

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

I suspect that multiple people have looked at / thought about / pondered 
it.  But there is a huge backwards compatibility issue.  Just look at 
how quickly the industry is adopting IPv6 which is somewhat backwards 
compatible with IPv4.  }:-)

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

Nicely done.

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

Was routing / forwarding not in kernel space?  Am I too young to 
appreciate routing / forwarding not being in kernel space?

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

This sort of reminds me of mirror / span ports on switches.

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

I feel like -- what I'm going to call -- the veracity of data is still a 
difficult problem today.  In fact, the only things that I'm aware of 
that address them in any capacity require various forms of cryptography 
to either sign and / or encrypt for subsequent verification / decryption 
by consumers.

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

How do you enforce such authorization or not without cryptography.  The 
only thing that comes to mind is that network equipment become WAY more 
Draconian and require static configuration of what is, and thus is not, 
allowed on various ports.

We can't even get people to implement uRPF on access networks to ensure 
that people aren't spoofing source IPs outside of said access network.

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

That is actually a really big ask.  Especially if you want to do it 
without cryptography.

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

I don't know that Flakeway violated L2.  Unless you are implying that it 
did so by receiving frames passing through multiple layers and then 
re-implementing L2 again in Flakeway in user space.  I say this because 
lying / ARP spoofing is done at layer 2.

Aside:  It is possible to run Ethernet networks with multiple (sets / 
pairs of) systems using duplicate IP addresses /as/ /long/ /as/ they 
have non-conflicting MAC addresses.  You do this by statically 
configuring ARP entries.  }:-)

A = .1 = AA:AA:AA:AA:AA:AA
B = .2 = BB:BB:BB:BB:BB:BB
C = .1 = CC:CC:CC:CC:CC:CC
D = .2 = DD:DD:DD:DD:DD:DD

Using static ARP entries on all systems,
A & B can communicate with each other
C & D can communicate with each other

If we extend this to include static ARP entries for all co-opereating 
systems in a network, we can be largely immune to IP spoofing.

Though there's not much that can be done about MAC spoofing.  And if 
someone is spoofing MAC addresses, they are likely also spoofing IP 
addresses.

> We recognized in the 80s that such protection mechanisms would be 
> difficult,

I think that they are still difficult today, in late 2022.

> and consume a lot of computing power that we didn't have, and require 
> protocols and mechanisms that did not yet exist.

Thankfully we now have some computing power to spare and some protocols 
that help with this; MACsec, IPsec, and TLS.

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

#truth

> So the "end-middle issue" was on the list of "things we need to do".
> 
> I guess it's still there.

I think it's fair to say that it's still on the list.

It's probably also fair to say many have never known about and / or have 
forgotten about it.



-- 
Grant. . . .
unix || die