From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8B1D03B2A4 for ; Mon, 23 Oct 2023 14:53:32 -0400 (EDT) Received: from mymail.myregisteredsite.com (jax4wmnode3b.mymail.myregisteredsite.com [209.237.134.215]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with SMTP id 39NIrHCq023973 for ; Mon, 23 Oct 2023 14:53:19 -0400 Received: (qmail 3627 invoked by uid 80); 23 Oct 2023 18:53:11 -0000 Received: from unknown (HELO ?192.168.1.100?) (jack@3kitty.org@76.137.180.175) by 209.237.134.154 with ESMTPA; 23 Oct 2023 18:53:11 -0000 Content-Type: multipart/alternative; boundary="------------QgHeOGJ4AXrQB4zOKxN1K565" Message-ID: Date: Mon, 23 Oct 2023 11:53:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: nnagain@lists.bufferbloat.net References: Content-Language: en-US From: Jack Haverty Autocrypt: addr=jack@3kitty.org; keydata= xsDNBGCm2psBDADGOWO8n9wfkDW9ZUEo8o+SZ5MU9us2il+fS4EFM/RaZFIbQ+P72bExzSd3 WnJdPfqO1O7Q+dRnvVO9+G2/9oT/uRZVaE05+SothzKZBv32HcZoUkdNZOTqSkdo3EwNPjid LLxX+dMBxMpR3pBdvGN8Z7lnZe6fV4QO2xtd58y3B33AVZJp+RuNwucby9dY2meyy2BJVKrx mKhYXAucVyg0ALVIchHt9UknVW4aLvQF+oMfzXVvCWeguW+DvbyazVceWGO7FSgUJ8ED3Ii7 xAR5zZJ1LASoMhG1ixg07P9Uy4ohV6c+c0yV9SY4yqhZ3+zN2cm9h/aXpwjSuiVVAJbK7zzb FjI+h89dbnaVQrLx6GikV0OVYqC6TCeMfCFZQAJLs1icxQi3BLL7O1fbTGatEfTgLa5nqfKq K/D/HlOCUeFxqZI8hXvT5dG4e1m3ilpF2/ytcWKSVg3d699UFntPv3sEbAQwwfXsnuD4Hem6 0Ao0/z41n8x1aeZE80FdkpEAEQEAAc0eSmFjayBIYXZlcnR5IDxqYWNrQDNraXR0eS5vcmc+ wsEJBBMBCAAzFiEEZLvMn5vmvTAlFEILdGzDIkA7jlAFAmCm2pwCGwMFCwkIBwIGFQgJCgsC BRYCAwEAAAoJEHRswyJAO45QuX0L/jOluv8fr/BmuEEQsWWGW6oARIbjDQrI93kXIJXuPnfp tGjkx/f1TMIzI2B9s/tejiYE7IZOhWbX1YvKF0UbkSJi50UyV9XtYRnLdD5TcksKB4luDF8S R+nj5WBm17Bp8qwriCMgA1jGL2wQ7J1KUw4Q/gsMcjhn/39PevswkriU2qqVplfCs9yTTMU5 SvtE2U9F3Y1ZINHn3kUysvxhRFd+Oh3PocWHmVE+hkII+qsra6z4eztDgoB+vqxmOJEdtvex GhT8OKu74DacguZVfu/AV+cwpX701sdjJrMyKjcv8uhFLM/E5gf6kSUAFxBVwe6pNDmAgmbS c0fAFrZjgXxNxxndpu/8OAUDVzKg+l5WJ0nWss9Q14BwA+FcoclO3lwzFu7jOiLvkm7jQkFB o+p8Owe4iAED1KK/aocIa/RiD4sZ3KXUJ92kkemZ1Qe2XpFVdzxaQDG0huNkc5Mie9rdt62O Ae+5cYdPeWmBVn+pFNs5H09kQQbVR5pUxe2Aps7AzQRgptqcAQwAzzougHNMFr/O/L8HnNJW 1YyOuX0PEVNUXQPwkxKuD8bAXsPr4Hv1a+840ByesiJSadhQgVSMruRqoQC5tTkbEWkqlfDW waNAdqCJOXl2T6gtK7RpcHNx7+/du/gCAhHOXqH1Qfs0Zi3YEbR/kQFRP3wD4GiCvHSny8zJ X9plIHqQGoE5DePNAtE2KimbFMsjguqJgq5x0tMf3qEaMNd0IGTStGpcC49iss71slotH091 Y1Yo9CpzL6rj8IP0BfssEujAvf3Gbf1oi92JRE3s2humFDfPvSlHmRIfWPQ4qFOw1zmlzsV1 eg83gErKbjaDdkbwQA85RTmMVKNVvonM80WB6jAg8tlJ5VlYlpbzASpJRNj+FL1LLBQxCbPU eFwrzqYgNvtdKR7j5nTgdndCxq+2aws/aAjdL10S8yeH7ZOpNPzjDJfMSt/L1O25zPUhXdQC 9AZNYsfyV7rf+POEgVpIEth1fT9WbmS0rZxRd/+y628n31GicbA+teN890vdABEBAAHCwPYE GAEIACAWIQRku8yfm+a9MCUUQgt0bMMiQDuOUAUCYKbanQIbDAAKCRB0bMMiQDuOUF1LC/4q 4pLtmDt6TIET2H7zGj5ie3ng7kC7YqtFPYwgLQzs9WeqQ/5WowEmHOPonBcqhGbtDj22GebQ 7w0RoUHb+aXsbC85I/C+nWgT1ZcfMBTHGlBcIQvOCNG18g87Ha9jgD0HnW4bRUkZmGMpP0Yd TLM+PBNu41AK6z82VPQrfTuPKqwAAS2FK/RpF2xB7rjpETzIPl9Dj9EAkRbviURIg0BQkmej l02FLzGmlTfBIDHBdEgzvD71Z5H9BP8DAbxBzonSTzx/KZyv7njSUzdVLW+5O/WzPgb4Qt4I jQd66LS9HWS1G7AcLjiSQAIf8v7JkX3NwtN+NGX5cmt2p0e9FOOKWXVgCIgPN3/712EEGAgq UUxuPEBD5DrRCgjZL40eHxQza2BAhoVoWopUCGZdCCZJP3iF7818wIph0U393DELG9NAGLJa qkoA8KBimXp9Rd2QvpA864JRy/REoEOEF9lm3clriLyEqaL/VMIQRhl/VSkUuez4Wr68eHus TFdwePg= In-Reply-To: Subject: Re: [NNagain] upgrading old routers to modern, secure FOSS X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2023 18:53:32 -0000 This is a multi-part message in MIME format. --------------QgHeOGJ4AXrQB4zOKxN1K565 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/23/23 10:58, Dave Taht via Nnagain wrote: > I wish that the city-dwellers of BEAD so in love with fiber would > insert 70ms of rural delay into all their testing. FYI, in case someone wants to pursue such real-world testing.... 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. That software is long gone, but might be easily rewritten today.  It was literally a weekend hack.   Here's how it worked. 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" 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..." 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). 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. But something similar might be possible in today's world to improve real-world testing? Jack Haverty --------------QgHeOGJ4AXrQB4zOKxN1K565 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/23/23 10:58, Dave Taht via Nnagain wrote:
I wish that the city-dwellers of BEAD so in love with fiber would insert 70ms of rural delay into all their testing.
FYI, in case someone wants to pursue such real-world testing....

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.

That software is long gone, but might be easily rewritten today.  It was literally a weekend hack.   Here's how it worked.

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"

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

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

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.

But something similar might be possible in today's world to improve real-world testing?

Jack Haverty

--------------QgHeOGJ4AXrQB4zOKxN1K565--