Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

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

It's not often that someone crafts a protocol expecting to destroy it, but that's what Cisco distinguished engineer Joe Hildebrand and a bunch of other Internet architecture boffins are doing right now.

When NSA whistleblower Edward Snowden talked of a protocol called SPUD – Substrate Protocol for UDP Datagrams – it piqued the interest of The Register's networking desk, and we headed over to the Internet Engineering Task Force (IETF) to read the draft blueprints, and thence to Webex to speak to Hildebrand, SPUD's author.

SPUD, Hildebrand told The Register, exists in the context of the IETF's and Internet Architecture Board's (IAB's) decision that Internet protocols need to become more resistant to monitoring. Concern was turned into policy in May 2014 when the IETF published RFC 7258, Pervasive monitoring is an attack.

The first thing to keep in mind about SPUD, Hildebrand said, is that nobody's ever going to see “SPUD support” as a sales feature of anyone's boxes, for good reason.

SPUD is never going to be deployed – it's explicitly designed not to be.

“It is clearly intended not to be deployed,” he said (our emphasis), and to make sure it's not, SPUD has no security.

It's a prototype protocol only, designed to test ideas: “will it work? Will it scale? What do you have to hide to keep user information private and confidential?”

One of the problems with privacy and confidentiality, Hilderbrand explained, is the information today's protocols have to give to “middleboxes” (anything between your host and the remote host) about the path your traffic is taking. So SPUD is also designed to help delineate what those middleboxes need to know, and what can be hidden from them without breaking the Internet.

Encryption

While security isn't written into SPUD itself, Hildebrand says, it does assume end-to-end encryption.

“A key element is that end-to-end traffic can be completely encrypted, as best as we know how, and in a way that lacks a backdoor, there's no MITM, and no ability for the network to trick you into giving access,” he said.

As anybody familiar with controversies like Verizon's stripping of the STARTTLS flag last year will know, network operators are wary of end-to-end encryption.

Hildebrand says part of that is that encryption can relegate operators to bit-pipes without a “value add”, because there's “no mechanism to exchange information with applications”.

It also erodes how operators manage their networks, he added.

However – at least as far as the IETF and IAB are concerned – end-to-end encryption is the future, so “from an architectural perspective we want to provide mechanisms to let operators try to add value, without having access to anything that puts the user at risk”.

That's a tough requirement, and yet another reason why a prototyping protocol like SPUD is important.

Similar topics

TIP US OFF

Send us news


Other stories you might like