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

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 …

[Paul Crawford]

Added value?

"we want to provide mechanisms to let operators try to add value"

Can anyone explain what "added value" is in this context? Why would I want it? (And I don't mean being whored to advertisers by my ISP)

[P. Lee]

Re: Added value?

You might want VoIP traffic to have higher-priority down your internet link than torrents.

Then you can happily run both simultaneously and have crystal clear calls and max speed torrents.

[Paul Crawford]

Re: Added value?

That is a good example, but I fear that ISP's would abuse the ability to rank and manipulate streams and app developers, for that matter, to lie about what they are to appear better to a customer.

[Anonymous Coward]

Perhaps add value in the sense they can transmit stuff more efficiently, reduce overhead, and either reduce costs or allow more traffic on the same pipe. Either way is an honest win.

[Paul Crawford]

The most obvious beneficial case is caching common and/or large volume stuff, something that was largely pissed on by DRM anyway and becomes impossible for always-encrypted traffic.

[cantankerous swineherd]

presumably they know all about this:

https://en.m.wikipedia.org/wiki/Recursive_InterNetwork_Architecture_(RINA)

[David Roberts]

OSI?

Sounds a bit like someone trying to re-invent the seven layer model.

[ScottAS2]

Re: OSI?

Yes, although bear in mind where we're coming from: TCP/IP doesn't follow the ISO-OSI model; TCP has always been a bit too ready to assume that it's operating over IP. If all we get out of this is a better separation of the transport and network layers, it'll be a win.

[Anonymous Coward]

Good start

As an application developer, I want the protocol to do all the heavy lifting. I don't want to have to code a lot of stuff into my app that shouldn't have to be there, and potentially get it wrong. I just want to be able to either create a connection, or receive a connection, and know that what I pass down that pipe will get there in a fast and secure fashion. Today, I find myself using API after API; MSMQ, signalR, IOCP->ImmutableStack, because the heavy lifting is bubbled up to the application layer. But its not like my requirements are fundamentally different to 99.9% of everyone else doing TCP development, who just need to get the data to get from A to B, or A to Many. If this means losing the 'value add' of rate-limiting protocol-massaging that my ISP believes is 'helping me', then so be it.

[Anonymous Coward]

Yawn... too much...

Let's start with the basics - TLS, DNSSEC, DANE.

Those are existing protocols that people should be deploying, but aren't...

[Anonymous Coward]

Re: Yawn... too much...

But TLS over TCP?

I think one of the suggestions pointed out is that if we assume encryption is part of the basic protocol, then we could remove some of the unnecessary layering.

It is good to have a logical stack like the OSI model but an awful lot of the protocols that we have are little more than hacks stacked on top of each other (NAT - I'm looking at you).

I do like the idea of stepping back and thinking really hard about a properly engineered stack solution.

[Doctor Syntax]

"the absolute intent is that we throw this protocol away"

There speaks a man who's read TMMM.

[Anonymous Coward]

TMMM === F.P. Brooks' TMMM?

Assuming TMMM === The Mythical Man Month (where Chapter 11 has the title Plan To Throw One Away). [Is there anything else it might be?]

Still essential (although obviously dated: e.g. microfiche references). Your scrummasters etc and indeed almost everyone else should Read This First. And it needn't cost anything but time.

Freely downloadable (presumably legitimately: how about an El Reg article about Archive.org one day?):

https://archive.org/details/mythicalmanmonth00fred

[Anonymous Coward]

This sounds good.

Some sort of proxying is needed to prevent IP address leakage. It'll make the old IP layer redundant but pruning it is probably too much to ask at this stage. Privacy next decade, efficiency a few decades later, maybe.

I wonder if anyone's got a working UDP-based implementation today that allows P2P gaming without exposing IPs to the other players or their ISPs; that's the gist of this. Then eventually SPUD's successor would standardize, optimize, and simplify such protocols, right? Nah... that's basically TOR; too much latency. We need ISP/backbone routers to support anonymous routing... verifiably... in a DDoS-proof manner. In all sincerity, good luck with that!

[Anonymous Coward]

You run into a Hard problem. Routing by definition involves a source and a destination. Think of an Internet packet like an envelope. In order for it to get to its destination, it needs a recipient, and in order for a return in case of a problem, it needs a sender. There's no escaping these requirements without envelopes getting dropped on the floor and lost. Given that, there is always an inescapable paper trail. And given there's always a demand for efficiency (if for nothing else than to conserve energy use), how do you balance out these conflicting demands?

[Anonymous Coward]

This is true, but a separation of the routing information and payload would be beneficial. For instance, assume the entire payload was deeply encrypted, adding a tag to say the payload contained encrypted video traffic would allow for as much information as an ISP should need to know for rate limiting, without having to deep packet inspect every last byte.

[Charles 9]

And the moment you do that, someone's going to cheat the system and simply encrypt everything and wrap them in packages describing security fixes or other high-priority sequential stuff. Back to Square One...

[Michael Wojcik]

FIN and RESET

That's "FIN and RST". The canonical name of the flag is "RST". If you're going to spell it out, it shouldn't be capitalized - and most definitely not in block caps.