On the use of udp -- too dangerous

[Cameron Byrne]

folks,

I bought this issue up over a year ago here

Aside from dns, UDP is the L4 protocol of volumetric abuse. Many networks have put in place network bandwidth and pps policers for UDP traffic. QUIC needs to adopt its own proper L4 protocol number to be unique from the policed abuse that happens as a result of reflection attacks associated with dns, ntp, chargen, ssdp and others on udp.

I understand you think that udp is easier for you to get around todays CPE nats, but i am tellIng you the udp packets drop when they crosses this policing threshold and quic will be in very unhappy place.

Its not just a cute slogan, udp is unreliable and there is not cute way around a router policer dropping udp.

It would be prudent to use something like rfc6555 happy eyeballs to fail back off of quic or between udp quic and new L4 quic. Unfortunatel, the situation with udp gets worse and worse by the day. I strongly suggest the quic googlers talk to the netops security googlers about the scope of these udp reflection attacks and state of practice on dealing with them... Then you will see that quic cannot thrive on udp

. UDP is not a clean slate, it is a sewer.

Regards,

Cameron

[Ryan Hamilton]

We considered this possibility when we started working on QUIC. We ran extensive tests in which we sent UDP packets from Chrome browsers all over the world to UDP server in various data centers. We saw a very high success rate. Now that we're farther along in the project we have experience running QUIC in the real world; actually browsing the web using QUIC. So far, it seems to work. But it's definitely possible that as we ramp up, we will hit unexpected obstacles like the ones you outline. It should be an exciting process!

Cheers,

Ryan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Tony Arcieri]

On Tue, Dec 16, 2014 at 4:28 PM, Cameron Byrne <cby...@gmail.com> wrote:

Aside from dns, UDP is the L4 protocol of volumetric abuse. Many networks have put in place network bandwidth and pps policers for UDP traffic.

I used to think this was the case, but after examining the empirical evidence and talking to multiple network engineers from both Juniper and Arista I think the situation may not be as dire as I first believed.

Here's a counterpoint based on real-world measurements:

http://openmymind.net/How-Unreliable-Is-UDP/

QUIC needs to adopt its own proper L4 protocol number 

That's a terrible idea, IMO. How would you do that without kernel support or raw sockets (i.e. root), and if you did that, why not use SCTP?

The clear advantage of using UDP is it can be done entirely with userspace and is fully compatible with the existing Internet, operating systems, etc.

If Google is pushing QUIC and there are networks with poor UDP handling (which I'm convinced isn't the default in most network gear, it would have to be a deliberate configuration), perhaps QUIC can get these ISPs to change their behavior.

--

Tony Arcieri

[Fedor Kouranov]

I would love to do a QUIC protocol number and save 8 bytes + checksum scan per packet.

The expectation is that it will be a lot worse than UDP on current networks, alas. So maybe some day.

QUIC does implement happy eyeballs.

--

[Christof Leng]

I think the L4 approach put SCTP into an unpleasant place (legacy NATs, misconfigured networks, kernel implementation needed, etc.). They recently decided that UDP tunneling is a viable approach (https://tools.ietf.org/html/rfc6951), more than a decade after being standardized as an L4 protocol. I don't think that QUIC would benefit from an L4 protocol number.

[Cameron Byrne]

On Tue, Dec 16, 2014 at 4:45 PM, Ryan Hamilton <r...@chromium.org> wrote:

We considered this possibility when we started working on QUIC. We ran extensive tests in which we sent UDP packets from Chrome browsers all over the world to UDP server in various data centers. We saw a very high success rate. Now that we're farther along in the project we have experience running QUIC in the real world; actually browsing the web using QUIC. So far, it seems to work. But it's definitely possible that as we ramp up, we will hit unexpected obstacles like the ones you outline. It should be an exciting process!

I hope the SRE's are up for that level of excitement.

in my case, the policers are at some multiple of normal busy hour traffic profile for UDP.... and UDP is a very  modest portion of overall traffic.  Generally, this is great at catching DDoS traffic while not impacting daily life.

But, if ... youtube were to flip over to QUIC, it would be game-over real quick.

At which point i will link the SRE to this thread for their RFO.

Cameron

Cheers,

Ryan

On Tue, Dec 16, 2014 at 4:28 PM, Cameron Byrne <cby...@gmail.com> wrote:

folks,

I bought this issue up over a year ago here

Aside from dns, UDP is the L4 protocol of volumetric abuse. Many networks have put in place network bandwidth and pps policers for UDP traffic. QUIC needs to adopt its own proper L4 protocol number to be unique from the policed abuse that happens as a result of reflection attacks associated with dns, ntp, chargen, ssdp and others on udp.

I understand you think that udp is easier for you to get around todays CPE nats, but i am tellIng you the udp packets drop when they crosses this policing threshold and quic will be in very unhappy place.

Its not just a cute slogan, udp is unreliable and there is not cute way around a router policer dropping udp.

It would be prudent to use something like rfc6555 happy eyeballs to fail back off of quic or between udp quic and new L4 quic.  Unfortunatel, the situation with udp gets worse and worse by the day.  I strongly suggest the quic googlers talk to the netops security googlers about the scope of these udp reflection attacks and state of practice on dealing with them... Then you will see that quic cannot thrive on udp

. UDP is not a clean slate, it is a sewer.

Regards,

Cameron

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/proto-quic/09L5YD2u5xU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to proto-quic+...@chromium.org.

[Cameron Byrne]

On Tue, Dec 16, 2014 at 4:51 PM, Tony Arcieri <bas...@gmail.com> wrote:

On Tue, Dec 16, 2014 at 4:28 PM, Cameron Byrne <cby...@gmail.com> wrote:

Aside from dns, UDP is the L4 protocol of volumetric abuse. Many networks have put in place network bandwidth and pps policers for UDP traffic.

I used to think this was the case, but after examining the empirical evidence and talking to multiple network engineers from both Juniper and Arista I think the situation may not be as dire as I first believed.

Here's a counterpoint based on real-world measurements:

http://openmymind.net/How-Unreliable-Is-UDP/

this is effectively just measuring packet loss under load between 2 data centers.

 

QUIC needs to adopt its own proper L4 protocol number 

That's a terrible idea, IMO. How would you do that without kernel support or raw sockets (i.e. root), and if you did that, why not use SCTP?

QUIC is a new stack in the OS, right? That is at least the target as i understand it.  

 

The clear advantage of using UDP is it can be done entirely with userspace and is fully compatible with the existing Internet, operating systems, etc.

That is fine for experiments.

 

If Google is pushing QUIC and there are networks with poor UDP handling (which I'm convinced isn't the default in most network gear, it would have to be a deliberate configuration), perhaps QUIC can get these ISPs to change their behavior.

Or Google can globally clean up UDP.  I am not holding my breathe.

Either way, my recommendation is not get in  the mud with the UDP mess if you plan to take this to prime-time.  Happy Eyeballs with 1) new protocol L4 2) UDP encap 3) fall back to legacy L4 would be most prudent.

CB 

--

Tony Arcieri

[Tony Arcieri]

On Tue, Dec 16, 2014 at 9:25 PM, Cameron Byrne <cby...@gmail.com> wrote:

That's a terrible idea, IMO. How would you do that without kernel support or raw sockets (i.e. root), and if you did that, why not use SCTP?

QUIC is a new stack in the OS, right? That is at least the target as i understand it.  

QUIC is a userspace library, which is probably it's main advantage over SCTP, which does require kernel modifications or root/raw socket access, specifically because it's an entirely different L4 protocol.

Building QUIC on top of UDP allows it to be a userspace library. Beyond that, it's written in C++, so it's unlikely to ever get merged into e.g. Linux

[Cameron Byrne]

Adding another data point to this thread that UDP 80 is a poor choice for QUIC since UDP 80 is common characteristics in massive DDoS events.

UDP 80 is actively being blocked not only at the Internet edge but also in the Internet core https://twitter.com/JobSnijders/status/581099707243622400

Please considered a unique L4 for QUIC with "happy eyeballs" style fall back to UDP

CB 

[Ryan Hamilton]

On Fri, Mar 27, 2015 at 2:10 PM, Cameron Byrne <cby...@gmail.com> wrote:

Adding another data point to this thread that UDP 80 is a poor choice for QUIC since UDP 80 is common characteristics in massive DDoS events.

UDP 80 is actively being blocked not only at the Internet edge but also in the Internet core https://twitter.com/JobSnijders/status/581099707243622400

Please considered a unique L4 for QUIC with "happy eyeballs" style fall back to UDP

 

​I definitely appreciate the concern here. However, the data we have suggests that actually QUIC running on UDP port 80 (for http:// traffic) works very well for the vast majority of users, and QUIC on port 443 (for https:// traffic) works well to. 

Alas, the data also suggests that the reachability of a new L4 protocol is dramatically worse. While I completely agree that this would be a much cleaner option, I don't think it's practical.​

[Jeff Kim]

>> the data we have suggests that actually QUIC running on UDP port 80 (for http:// traffic) works very well for the vast majority of users, and QUIC on port 443 (for https:// traffic) works well to. 

Hi Ryan- Does this include mobile/wireless networks?  If so, are you able to share this data?

--

You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

[Ryan Hamilton]

Yes, it does include mobile. Working on the details of sharing some data. Stay tuned.