Advisory Guidelines for UDP Deployment | Hacker News Reader

Advisory Guidelines for UDP Deployment

tools.ietf.org

24 pointscambyrne21 comments

> application and protocol developers should avoid using UDP as a transport when possible.

Thank you for your thoughts, but can you also provide an alternative solution to best-effort, non-ordered, low latency package delivery?

Without that a wide swath of applications (e.g. latency-sensitive gaming) will become literally impossible to implement, and i do not think the recommendation of IPSec is useful for all applications.

Many real-time applications can tolerate some packet loss, and if packets arrive out-of-order there's no benefit to re-sending them. I'm thinking of real-time games and VoIP, for example. TCP is a bad fit for these use cases. The only thing that works across nearly all routers is UDP.

I'd be more interested in making UDP more secure (and learning more about best practices) than to "avoid using UDP as a transport when possible".

I think they meant, avoid using over the internet.

I mean using these things over the Internet. People play games over the Internet and use VoIP over the Internet. I think these are great technologies, and I don't want to cripple them by forcing them onto TCP.

True, i guess the author is thinking of over saturating a link and forgetting there are a class of problems that are fine with packet loss. Lots of networking SMEs live in complete fear of multicast on a LAN

Cam, why would you ban UDP when you fix source routing at layer 3 instead? The amplification attacks depend on IP transit providers routing packets from ports with a source route in that packet that arrive from an interface where they could not possibly have originated. Every router knows from static inspection of its route tables which interface a packet with the bogus packets source route would get sent to it if were the destination. And it knows what interface the packet came in on. It could instantly squelch the packet right then and there if there was a mismatch.

that doesn't help you when the spoofed packets come in on a default route because somebody else's network is poorly configured. Nor does it help the person the spoofed attack is directed at.

This sounds like a job for a coordinated botnet to experiment with. A master controller sends hosts in the botnet a list of a few other devices it controls. The infected host A sends infected host B a spoofed UDP packet (or a series of packets with different spoofing options). Host B then sends the master controller which packets it received and now a map can be made of which networks allow spoofing.

Internet network flows take mysterious ways. Well, not really, but it is difficult and there are szenarios where carriers would be different for inbound/outbound traffic to a certain destination. Thus, I don't think the premise that routers should know if the source of a packet is valid really holds true.

This exact suggestion is referenced in the article.

"To prevent the spoofed reflection attacks, all network operators should implement anti-spoof address filtering [RFC2827]. This prevents the trigger of the DRDoS."

http://tools.ietf.org/html/rfc2827

"This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point."

> Every router knows from static inspection of its route tables which interface a packet with the bogus packets source route would get sent to it if were the destination.

It's considerably more complicated than that. Also, as much as we might try, BCP38 adoption is terrible.

Given the social and technical problems with BCP38 adoption I doubt we'll see source address verification in our lifetime. It's a mess. The SAVI WG at the IETF Is working on this, but it's a very tough problem.

For those less IETF savvy, this is an individual draft, which anyone can author and upload. It's not assigned to any WG, nor is it any sort of policy (in fact it's very much not in alignment with any of the IETF's recent work)

Quite a strange idea. The source IP spoofing problem mentioned in the draft has a known "solution" - making ISPs check source addresses before routing. I get it ain't very easy, but stopping using UDP wouldn't be easier anyway.

The proposal is especially strange when you consider that almost nobody uses UDP, TCP (ok, let's be honest: HTTP) is the "default" protocol for everything. Those who do use UDP, usually have quite a good grasp of what it is and when it should be used (VoIP, video broadcasting, DNS, uTP).

It would be much more productive to describe how UDP application protocols can be designed so that they aren't good sources of reflected DDOS.

Probably it would be an equivalent of the three way handshake to make it extremely hard to fake source address.

The original title of this document is "Advisory Guidelines for UDP Deployment". HN Guidelines (see the link at the bottom of the page) specify that you should use the original title unless it's misleading or linkbait.

Fixed

Thank you!

Sounds like a violation of net neutrality. Extremely convenient excuse to throttle the new P2P protocols that are emerging and threatening to run over the top of the networks.

What is a "baseline" UDP load? And why not just filter on the attacking DNS requests? At worst you'd have to spoof responses and act as a caching proxy.

The UDP protocol unlike TCP does not have congestion control. This means that if both protocols share the write the TCP will always back off and let UDP use as much bandwidth as it wants.

Because router speed is not unlimited effectively UDP will reduce TCP's performance.

Also if UDP traffic would grow, there is the danger of congestion collapse, which means that one day the Internet would simply became so slow it would be unusable. This already happened in second half of 80s and was solved by adding congestion control and avoidance to TCP.

Why not add it to UDP? You might say. There were attempts, but are unsuccessful due to connection less nature of UDP.

This move is totally understandable and provably only thing we can effectively do today. I also don't think net neutrality can be applied here, since there is no discrimination of specific communication between two parties. All UDP traffic is limited it doesn't matter who is using it.

Has T-Mobile provided any evidence that their network is actually congested?

They made the claim in this draft that it is/was, but then failed to show or link to anything that would corroborate the claim.

At the same time, T-Mobile benefits by blocking traffic that may compete with T-Mobile's other offerings (p2p voice/video connections).

Reply on news.ycombinator.com