Live data from Hacker News

Advisory Guidelines for UDP Deployment

tools.ietf.org

21–23 of 23 posts

Re: Advisory Guidelines for UDP Deployment

#21
post #4

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 we…

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.

Re: Advisory Guidelines for UDP Deployment

#22
post #7

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…

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.

Re: Advisory Guidelines for UDP Deployment

#23
post #22

Earlier quoted context omitted.

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
Post reply on HN