Advisory Guidelines for UDP Deployment
tools.ietf.org
Advisory Guidelines for UDP Deployment
1–10 of 23 posts
Re: Advisory Guidelines for UDP Deployment
#2The 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.
Re: Advisory Guidelines for UDP Deployment
#3The 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
Re: Advisory Guidelines for UDP Deployment
#4Cam, 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.
Re: Advisory Guidelines for UDP Deployment
#5Cam, 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.
Re: Advisory Guidelines for UDP Deployment
#6> 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.
Re: Advisory Guidelines for UDP Deployment
#7Many 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".
Re: Advisory Guidelines for UDP Deployment
#8Cam, 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…
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.
Re: Advisory Guidelines for UDP Deployment
#9It would be much more productive to describe how UDP application protocols can be designed so that they aren't good sources of reflected DDOS.
Re: Advisory Guidelines for UDP Deployment
#10Cam, 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…
[deleted]