<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 10/23/23 10:58, Dave Taht via Nnagain wrote:<br>
<blockquote type="cite"
cite="mid:CAA93jw5z7sx=DYUOXNh9CF22xhHbqLrpP9_i=+mQQDYuks10PA@mail.gmail.com">I
wish that the city-dwellers of BEAD so in love with fiber would
insert 70ms of rural delay into all their testing.</blockquote>
FYI, in case someone wants to pursue such real-world testing....<br>
<br>
When we were testing TCP/IP software about 40 years ago there was a
similar problem of how to do tests in a lab which realistically
simulated real-world conditions. We created a software tool called
"Flakeway" which enable traffic flows to be delayed, duplicated,
re-ordered, deleted or mangled. That enabled realistic testing
even when the machines being tested were all in a lab connected to
the same LAN.<br>
<br>
That software is long gone, but might be easily rewritten today. It
was literally a weekend hack. Here's how it worked.<br>
<br>
The basic design took advantage of a "feature" of the IP protocols.
When an IP datagram is to be sent to another computer on the same
Ethernet, the IP address isn't big enough to encode the Ethernet
address. So the ARP mechanism is used to get the appropriate
mapping between an IP address and the required Ethernet address for
the destination host. The sender issues an ARP request that says
"Where is IP address x.x.x.x"? The computer which is configured as
that IP address responds with "It's me, and my Ethernet address is
xx:xx:xx:xx:xx:xx"<br>
<br>
When the Flakeway, running on some other computer on the same LAN,
saw such an ARP exchange for a traffic flow it was supposed to
manipulate, it would immediately send it's own ARP response, saying
"No, it's me, and my Ethernet address is..."<br>
<br>
We discovered that most computers simply believed the latest ARP
information it received. So it was easy for the Flakeway to insert
itself into any IP traffic flow and do its work, without any changes
to software in any other computer. It was handy not only for
testing but also for diagnosing all sorts of problems, simply
capturing the traffic flows for later analysis (similar to
wireshark).<br>
<br>
That was all done in the IPV4 world, 40+ years ago, so I'm not sure
how it might relate to today's Internet. We reported this
"feature" to IETF and some IEEE 802.x committee as a likely
vulnerability, but I'm not sure if anything changed.<br>
<br>
But something similar might be possible in today's world to improve
real-world testing?<br>
<br>
Jack Haverty<br>
<br>
</body>
</html>