[ih] history of protocol bugs

Gergely Buday gbuday.irtf at gmail.com
Sat Nov 11 02:03:23 PST 2023


On Fri, 10 Nov 2023 at 13:50, Craig Partridge <craig at tereschau.net> wrote:
>
> Fun question and it also raises the question of "what's a bug?"  So, for instance, here are 3 TCP "bugs" -- which of these are the kinds of bugs you're interested in?
>
> 1. 20 years ago, a software vendor shipped code that computed the wrong checksum on a FIN-ACK if the FIN-ACK had to be retransmitted.

>From a user's perspective, this is definitely a bug, but not in the
protocol, but in the implementation.

Would any stakeholder: the IESG, vendors, RFC authors be interested in
formally verified reference implementations of protocols? Some said
that the IETF is not interested.

> 2. In 1974, Ray Tomlinson was using an early TCP to connect to a printer and his host kept crashing and he discovered printer outputs that combined data from multiple TCP connections because every TCP connection was starting with sequence number 0 when the host rebooted.  He realized that TCP needed a way to select initial sequence numbers that prevented old segments from being confused with new segments.

This I call a bug in the protocol.

> 3. Around 1990, people realized that the TCP sequence number space was too small for gigabit links and a TCP option was developed to expand the sequence space.

As someone suggested, this is an enhancement to a new environment,
where large amounts of data in one connection should be possible.

> All three could be described as bugs: #1 - failure to implement spec, #2 -  failure to recognize a potential failure point, and #3 - failure to anticipate evolution.  Or you could say just #1 was a bug and #2 and #3 were learning experiences.  Or you could label #3 as simply a growth issue that was deferred by the original designers.....
>
> Which of these bugs (or kinds of bugs) do you want to track?

I joined the Usable Formal Methods Research Group of the IRTF to
tackle protocol bugs during the design of the protocol with formal
methods.

Formal methods are just tools, what matters is what properties I want
to check with them. And here learning history is essential.

- Gergely



More information about the Internet-history mailing list