I like this a lot. My own conworld also involves quadrupedal sophonts (aliens rather than animals), and I’ve thought about writing RFCs for some of their communication protocols.

YAP (yinrih ansible protocol) is a link layer protocol that manages messaging on an ansible link. Communication via ansible is very low bandwidth, meaning interplanetary networks look like 80s BBS’s or very very early (we’re talking still at CERN) websites. Ansibles use a kind of subspace called the Underlay. In order for two ansibles to communicate, they must contain wafers of tailstone shaved from the same monocrystal. Raw tailstone (or tailstone precursors) are mined and manufactured into monocrystals in a similar process to how silicon ingots are grown. At a certain point in this growth process, the crystal “locks”, and any wafers shaved from that monocrystal will only communicate with other wafers from the same monocrystal.

The Underlay link is shared between all such wafers, similar to a shared wifi channel, so individual ansibles have to take turns sending frames. You can achieve full duplex communication by growing two seperate monocrystals, shaving two wafers from each, and placing one wafer from each crystal into two ansibles, with one serving as an RX interface and its partner on the other ansible serving as TX, and vice versa. In practice, this is only done on high capacity trunk lines, as more underlay links require more power.

State actors can perform a supply chain attack by ordering a tailstone fab to grow monocrystals twice as large, break them in half, send half downstream to their customers and give the other half to the government, which can spy on communications made via those ansibles undetected or perform MITM attacks.

YIP (yinrih internetworking protocol) is a network layer protocol that can serve either in a reliable or best effort configuration. While the address space of the original YIP was exhausted millennia ago and a new, but incompatible, YIP version developed with a much larger address space, there are still single-stack networks using the older protocol at the time of First Contact.

Because yinrih evolved writing rather than inventing it, their digital age stretches back to the mid-Pleistocene despite only gaining sapience around the same time as humanity, and because yinrih live over 700 Earth years on average, their networks are built to be apocalypse-proof. With such robust networks with enough uptime to be measured in geologic terms, some networks are left to run forgotten for millennia. This gives rise to the discipline of cyberarcheology, which specializes in ferreting out these archeonets and uncovering their secrets. Cyberarcheologists are experts in defunct communication protocols, obsolete storage formats, and long outmoded hardware architectures.

Thank you!

but what would happen if a new dispatch needed to be issued mid-flight (e.g., due to weather or airspace disruption)? Would a different system handle that?

That would go through no problem, and since the hovercraft keeps track of what entry ID it’s currently executing, you can give it extra steps by rearranging/adding entries after the current one (ATC would also be able to poll the hovercraft for its current entry ID)

In the worst case scenario, ATC can call up the pilot, ask them to disconnect the autopilot, stop the hovercraft in midair, and tell the hovercraft to wait for a brand new dispatch message. Once it has received such a message, the pilot can manually select which entry ID it should start at, and then reconnect the autopilot.

awestruck horror that they would let such a critical system exist without checking or validating inputs.

I have also written a post from a cat working for the Feline Ministry of Transportation, think of it as something that would be commented on their equivalent of /c/programming under a link to this report. Thought you might enjoy!

FMT/FTDMS dev here, thought I’d shed some light on what happened on our side.

This was found during a Ministry of Security audit as part of their Safe Infrastructure initiative. All of this was legacy code that hadn’t been touched in ages, the oldest of which dates back to before the Felines had even signed the ISPA and stopped eating prey. Yes, FDTMS as a protocol only became an official thing after the Feline Revolution (and by extension us signing the ISPA), but before that was a dozen different ad hoc ATC standards used by different parts of Feline Territory, and some of the source code from those (namely parts of Flight Dispatch Protocol, the old standard used in Moonpeak where all the government ministries are headquarted) were reused for FDTMS because it seemed easier and faster than writing everything from scratch.

All four points in the official root cause analysis can be boiled down to “cats are lazy” and/or “cats are bad at communicating with each other.”

1. Parsing the message before checking message signature: The message parsing and cryptography teams didn’t adequately consult with each other and failed to make sure their components were executed in the correct sequence. Both teams worked on their own thing and assumed that as long as both were done between receiving the message and prompting the pilot to accept the final dispatch table, there would be no problems. What happened was that the message processing and signature checking happened simultaneously on different threads. In theory, the cryptography thread could stop the message processing as soon as it detects an issue, but in practice, the message processing was way faster so by the time the cryptography thread finished and returned a result, the message had already been parsed and has overflowed the buffer. This was changed to a synchronous system where the cryptography thread executes first, and it is now the one responsible for triggering subsequent data processing threads if and only if it doesn’t detect any issues.

2. Failing silently on an invalid dispatch and reverting to the previous one: This was actually intentional because cats in the flight deck/ATC centre didn’t want to have to click two extra buttons whenever a dispatch message got corrupted during transmission. So the system was designed to be as automatic and “paws off” as possible. In theory, the pilot is supposed to check that the reversion to the previous valid dispatch is the correct action when they get a dispatch rejected message, and also report the error to ATC, but in practice that pretty much never happens. This was part of the code that was reused from FDP, and this whole thing was a really stupid idea and we only realized that after we found this issue.

3. The parser being more tolerant than the the actual FTDMS protocol: The standard originally treated TerritoryChange and RegionChange as completely different entries, but it got changed to a single entry fairly late in development because we realized that crossing a territorial border always implies crossing a regional border since the other territory would have its own regions. So buildDispatchTable had already been implemented and had to be updated. The cats who updated it figured that they only had to implement support for including the region information in TerritoryChange and didn’t need to completely remove support for two separate entries (because that would have been more work). But they also forgot to test that the changes made to TerritoryChange didn’t affect the ability to safely accept two separate entries (because the standard was being changed to disallow that anyway) and this is actually where the buffer overflow originated.

4. All of FDTMS-Client being run in privileged context with no Secure Mode protections that could have detected the buffer overflow/prevented privileged memory from being overwritten: WhiskerOS Secure Mode is really strict and honestly a pain in the tail to deal with, especially in terms of getting privileged and non-privileged code to talk to each other. So in classic cat fashion, we said “screw it” and made the entire codebase privileged so we wouldn’t have to deal with that. Actually, now that we’ve had to transition to a more restrictive privilege model, we’re getting a lot of issues with interprocess communication as expected. I actually got reassigned to a team specifically for dealing with complying with Secure Mode’s restrictions.

I also want to say that things are getting better, and from my experience, the Feline Government actually has way superior work culture than most other software development places in Feline Territory. But a lot of that old fashioned, counterproductive, least-effort Feline culture is still present especially in legacy code or massive codebases where many teams have to collaborate.