SPUD – The IETF's anti-snooping protocol that will never be used

Author Joe Hildebrand explains why a dead-end effort to reinvent networks isn't futile

Don't just do something, sit there and think

It also represents a different way of doing things for the IETF, where the vast number of RFCs attests to a long history of a “just do it” attitude.

Instead, with SPUD, Hildebrand and many others are trying to take an architectural approach – in line with the IAB's stack evolution program.

That program, he says, is “confusing and scary to a lot of people. “ They worry, he said, that they will be handed an edict, and that's not what's intended.

“The process is more like gathering people together with opinions, exchange those opinions, and suggest things to the community”. It's a process of seeking a consensus on the Internet's future, before people hit the keyboard and start coding.

Nor was SPUD solely conceived as a security/privacy protocol. It's worth mentioning, at this point, that Hildebrand's role at Cisco is engineering for its cloud collaborative applications, which gives him a daily exposure to how things like Webex can go wrong, and how the lower layers can help.

Hildebrand told The Register SPUD was also conceived as a response to a more general question: “What's wrong with TCP?” (the Transport Control Protocol that carries so much of the Internet's traffic).

For example, realtime voice and video don't suit TCP, but in terms of non-TCP, “there's a limited palette of choices on today's Internet”.

“There are new transport protocols that are better than TCP,” he noted, but none of them are deployed at significant scale because the Internet's infrastructure suffers from the ineradicable inertia of its installed base.

“There are lot of middle boxes on the Internet that know TCP and try to 'optimise' it”, he said, so it's important not to “infuriate” the people that run those middle boxes.

Slapping together a new protocol to go with a new application looks easy to the application developer – after all, it's only a few hundred lines of code – but if (for example) a firewall vendor is expected to support every new application by adding code, it accumulates very quickly.

“If you could figure out how to get them to implement one thing, just once, you might be able to get them to do it”, he said.

That led to an IETF discussion in London, he said: “instead of allowing a thousand flowers to bloom on top of UDP, could we do a bit of architectural work to allow us to support a wide range of transport protocols instead of 'just one more'?”

Consultation with firewall experts told him that there are many aspects of TCP they like and want preserved

• TCP has an explicit start to a conversation (via SYN and ACK) that helps preserve information about who initiated contact;
• The TCP sequence number lets the firewall “tie packets in the stream back to that explicit start,” making it easy to craft rules about what to allow.
• TCP knows when to shut down a conversation and clean up its associated resources (FIN and RESET).

“There are some UDP protocols that have those, but each does it differently,” he said – which the architectural work aims to clean up.