

Advisory Guidelines for UDP Deployment - cambyrne
http://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

======
Mithaldu
> 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.

------
spin
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".

~~~
easytiger
I think they meant, avoid using over the internet.

~~~
spin
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.

~~~
easytiger
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

------
ChuckMcM
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.

~~~
throwaway2048
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.

~~~
pixl97
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.

------
TD-Linux
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)

------
skarap
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).

------
caf
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.

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

------
greenyoda
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.

~~~
cambyrne
Fixed

~~~
cpach
Thank you!

------
jsprogrammer
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.

~~~
takeda
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.

~~~
jsprogrammer
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).

