7 ms·

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of a

by axaxs 7y ago

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

faeyanpiraat 7y ago
curmudgeon (noun): a bad-tempered person, especially an old one.
john37386 7y ago
Totally agree with you. Many big corporations totally block UDP at ISP level because there is no easy/magic solutions against amplified DDoS. They usually use some internal backend for DNS, Ntp, routed through other ISP. I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.
- microcolonel 7y ago
  The fact that many corps block UDP doesn't have anything to do with the necessity of QUIC. QUIC is on top of UDP because we tried with SCTP, but is never coming. For people who have reasonably configured UDP, it offers a benefit; the fact that some people have broken UDP is neither here nor there. HTTP/2 continues to be an option for TCP-only networks.
- profmonocle 7y ago
  > I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility. Presumably most HTTP/3 implementations will gracefully fall back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing QUIC implementation already does this. Every Google property has had QUIC enabled for quite a while now (at least 4-5 years), so if UDP blocking would cause availability issues, affected businesses would've noticed by now.
  - wahern 7y ago
    In 2017 Google reported that "4.4% of clients are unable to use QUIC". See sec. 7.2 of https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf https://static.googleusercontent.com/media/research.google.c....
    - profmonocle 7y ago
      Sure, but that doesn't mean those clients are unable to connect to QUIC-enabled domains. Chrome detects that the UDP packets are being lost, disables QUIC, and falls back to HTTP/2.
- tracker1 7y ago
  Many corporations also block SMTP and inbound host ports... doesn't mean the protocol is bad. Hell, many corporations install horrible proxy servers and require all outbound connections go through that proxy.
zamadatix 7y ago
It is slapped together TCP over UDP. They would rather have made it over IP but protocol ossification has made that impossible. Don't think of it being UDP as anything more than "it happens to go through existing infrastructure without any or much work"
nikeee 7y ago
It's fun to see how we kind of reinvented goold old DNS as soon as we use HTTP/3 for DoH. It runs on UDP, but with HTTP in between (and encrypted, of course). We could have done that with DNS itself, but somehow this never gained traction.
- zamadatix 7y ago
  The difference DoH started with something nearly every network was guaranteed to have allowed: HTTPS traffic on TCP 443. Trying to wait for every network to allow DNS on 31218 or whatever wouldn't have worked. Even with a massive amount of the web guaranteed to move to HTTP/3 there will be places that still don't allow UDP 443 five years from now. If ever something seems dumb in network protocol design the answer probably lies with ossification. Hopefully the design of HTTP/3 ends that.
  - gsich 7y ago
    You don't need to wait. Just offer your service on that port and you are done. Why build protocols with shitty networks or shitty admins in mind? You can use most ports just fine. Multiplayer games show this every day. If those don't work in corporate networks (I include "public" wlan in this) that's fine too. It's not up to you what should be allowed or not in a company setting. ISPs don't block ports just for fun. And if you are big enough like Google or Facebook, just offer a service only on that port. If it doesn't work, show a warning that the customer should complain to the network owner.
paulddraper 7y ago
Forget the narrow waist of the internet; this is the spaghetti ball of the internet. It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. If you have a better transport layer, fine. Make a better transport layer. But rolling the whole thing is the best way to ensure nothing will ever get done. HTTP/3 is the new IPv6.
- yzmtf2008 7y ago
  > It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. I mean, it's not like encapsulation and decoupling ever worked with the networking stack. For example, let's pause a minute and think about which layer does TLS or NAT sit in. To quote @tptacek[0]: There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are such things. > HTTP/3 is the new IPv6. Funny you mentioned IPv6. The famous article [The world in which IPv6 was a good design][1] actually gives some good context on why QUIC is needed, and believe it or not, layering violation was explicitly mentioned. [0]: https://news.ycombinator.com/item?id=4556125 https://news.ycombinator.com/item?id=4556125 [1]: https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810
  - paulddraper 7y ago
    > which layer does TLS Transport Layer Security? Transport layer. > which layer does NAT Network Address Translation? Network layer. --- That said, the names aren't as important as the layer and independence. E.g. TLS can be used to secure any TCP traffic: STMP, HTTP, etc.
    - yzmtf2008 7y ago
      Some might argue that TLS is on Layer 6, 7 and 4 at the same time: https://security.stackexchange.com/a/93338 https://security.stackexchange.com/a/93338 Same for NAT: https://networkengineering.stackexchange.com/questions/3145/what-layer-of-the-osi-model-does-nat-work https://networkengineering.stackexchange.com/questions/3145/... > the names aren't as important as the layer and independence That's the point. Layers don't mean anything in the real world where ossifications are a thing and replacing infrastructures has a cost. There are plenty of protocols that require cross-layer coupling (aka "layering violations") and asking for layering compliance really doesn't make anyone except layering lawyers' life better.
manigandham 7y ago
Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.
- kazen44 7y ago
  implementing a new version of TCP would be nearly impossible because of all the equipment out in the field already. Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
  - manigandham 7y ago
    Why doesn't the IP protocol require new hardware if it's a lower layer?
    - watersb 7y ago
      IP doesn't require new hardware because it's a lower layer. Transmission Control Protocol - TCP - is baked into the firmware of every client network interface card, and I would suppose in almost all of the switches and routers of business infrastructure. I have no idea what data centers use. Infiniband and similar things aren't TCP, I think.
      - lizknope 7y ago
        Infiniband is a lower level than TCP. Infiniband is often used as a replacement for ethernet in a supercomputing cluster. If you wish you can run IP over Infiniband (IPoIB) but I think most people using Infiniband are running a lower latency protocol like RDMA https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoIB) https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoI...
      - manigandham 7y ago
        Is IP not handled by network devices and firmware? If it's just software then why don't we have IPv6 everywhere already?
baby 7y ago
It is basically TCP 2.0 implemented on top of UDP. What concerns do you have with this?
- axaxs 7y ago
  Well, I have a lot, but I don't want this to turn into a dissertation about why I don't like UDP for most things. The biggest red flag to me is that it is trivial to make the server send sizable packets to clients who didn't ask for them nor want them. Spoofing is not a solved problem, no matter how many times people scream at providers to block it before it gets out. Why isn't there a minimal ACK process up front? I mean, this thing is designed such that it's vulnerable to reflection attacks on -day 1-.
  - baby 7y ago
    UDP is a 4-page RFC that is pretty much a definition of IP with ports. You can easily imagine TCP as a bunch of algorithms on top of UDP. Knowing that I’m not sure what you don’t like about UDP? Amplification attacks and spoofing are taken care of by QUIC, so these are not problems at the moment.
    - axaxs 7y ago
      That's a little unfair. When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top. UDP is simple and quick, and the assumption is that there was a reason they chose that route. AFAICT, QUIC loosely defines a way to do client address validation, but it isn't required! It's worded as 'CAN' and 'MAY' in places, and places outside the spec basically hint that 'oh no! it adds another round trip'. This makes it feel totally bolted on. Why wasn't it required up front? If someone came up to me with this idea of QUIC, the -first- thing I'd tell them is to solve this problem definitively first. The idea seems sound to me, but not if you let everyone turn it off...
      - magicalhippo 7y ago
        > When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top. AFAIK it's rather common in multiplayer games to do TCP-like features over UDP, as they usually need the UDP features but also need reliable transport for some data, and it's rather tricky to do both UDP and TCP at the same time. See for example https://fabiensanglard.net/quakeSource/quakeSourceNetWork.php https://fabiensanglard.net/quakeSource/quakeSourceNetWork.ph... or https://gafferongames.com/post/reliability_ordering_and_congestion_avoidance_over_udp/ https://gafferongames.com/post/reliability_ordering_and_cong...
taf2 7y ago
Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?
- axaxs 7y ago
  There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records. However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflection. See, in TCP, every connection starts with a tiny three way handshake. So if you spoof the IP, the target would just get an unknown SYNACK which is tiny. It wouldn't respond, and nothing further happens. In UDP, there is no such handshake. So the target gets the entire response. So in short, DNS amplification attacks are only useful with reflection, which doesn't work over TCP.
  - srj 7y ago
    QUIC addresses this, like TCP it's a connection based protocol. It's just implemented in user space on top of UDP. The server response is required to be smaller than the client hello.
  - tialaramex 7y ago
    QUIC has address validation, basically if you talk back and forth with a remote party you can get yourself a token which proves you're on path (you might really be 10.20.30.40 we can't tell, but we can tell you can intercept packets for 10.20.30.40 because you received this token we sent there, maybe you're an adversary at their ISP) and you can use that token in future to prove you're still on path for 10.20.30.40, which an off-path attacker wouldn't be able to do because they can't get that token. So this lets you prevent amplification. If somebody asks a question with a long answer, but doesn't provide the token to prove they're on path, you make them go around again first, a legitimate user sees one round trip wasted to get a token but attacks don't work..
throw0101a 7y ago
> I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. They tried with SCTP and DCCP.
rstuart4133 7y ago
> DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP... Unlikely, since TCP + TLS implemented over UDP is a better description of QUIC. Neither TCP nor UDP were designed when you had to assume the internet to be a battle ground which pitted hackers, police forces, nation states against each other, and you. In such an environment it's not at all surprising to hear Comcast was attacking their own customers using bit torrent or competing video streaming by sending them fake TCP RESETS. But TLS on the other hand - that's exactly the environment TLS is designed for. They are not going to find it so each to screw with QUIC, because TLS is baked into its DNA.

by axaxs 7y ago

faeyanpiraat 7y ago

curmudgeon (noun): a bad-tempered person, especially an old one.

john37386 7y ago

Totally agree with you. Many big corporations totally block UDP at ISP level because there is no easy/magic solutions against amplified DDoS. They usually use some internal backend for DNS, Ntp, routed through other ISP. I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.

microcolonel 7y ago
The fact that many corps block UDP doesn't have anything to do with the necessity of QUIC. QUIC is on top of UDP because we tried with SCTP, but is never coming. For people who have reasonably configured UDP, it offers a benefit; the fact that some people have broken UDP is neither here nor there. HTTP/2 continues to be an option for TCP-only networks.
profmonocle 7y ago
> I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility. Presumably most HTTP/3 implementations will gracefully fall back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing QUIC implementation already does this. Every Google property has had QUIC enabled for quite a while now (at least 4-5 years), so if UDP blocking would cause availability issues, affected businesses would've noticed by now.
- wahern 7y ago
  In 2017 Google reported that "4.4% of clients are unable to use QUIC". See sec. 7.2 of https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf https://static.googleusercontent.com/media/research.google.c....
  - profmonocle 7y ago
    Sure, but that doesn't mean those clients are unable to connect to QUIC-enabled domains. Chrome detects that the UDP packets are being lost, disables QUIC, and falls back to HTTP/2.
tracker1 7y ago
Many corporations also block SMTP and inbound host ports... doesn't mean the protocol is bad. Hell, many corporations install horrible proxy servers and require all outbound connections go through that proxy.

zamadatix 7y ago

It is slapped together TCP over UDP. They would rather have made it over IP but protocol ossification has made that impossible. Don't think of it being UDP as anything more than "it happens to go through existing infrastructure without any or much work"

nikeee 7y ago

It's fun to see how we kind of reinvented goold old DNS as soon as we use HTTP/3 for DoH. It runs on UDP, but with HTTP in between (and encrypted, of course). We could have done that with DNS itself, but somehow this never gained traction.

zamadatix 7y ago
The difference DoH started with something nearly every network was guaranteed to have allowed: HTTPS traffic on TCP 443. Trying to wait for every network to allow DNS on 31218 or whatever wouldn't have worked. Even with a massive amount of the web guaranteed to move to HTTP/3 there will be places that still don't allow UDP 443 five years from now. If ever something seems dumb in network protocol design the answer probably lies with ossification. Hopefully the design of HTTP/3 ends that.
- gsich 7y ago
  You don't need to wait. Just offer your service on that port and you are done. Why build protocols with shitty networks or shitty admins in mind? You can use most ports just fine. Multiplayer games show this every day. If those don't work in corporate networks (I include "public" wlan in this) that's fine too. It's not up to you what should be allowed or not in a company setting. ISPs don't block ports just for fun. And if you are big enough like Google or Facebook, just offer a service only on that port. If it doesn't work, show a warning that the customer should complain to the network owner.

paulddraper 7y ago

Forget the narrow waist of the internet; this is the spaghetti ball of the internet. It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. If you have a better transport layer, fine. Make a better transport layer. But rolling the whole thing is the best way to ensure nothing will ever get done. HTTP/3 is the new IPv6.

yzmtf2008 7y ago
> It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. I mean, it's not like encapsulation and decoupling ever worked with the networking stack. For example, let's pause a minute and think about which layer does TLS or NAT sit in. To quote @tptacek[0]: There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are such things. > HTTP/3 is the new IPv6. Funny you mentioned IPv6. The famous article [The world in which IPv6 was a good design][1] actually gives some good context on why QUIC is needed, and believe it or not, layering violation was explicitly mentioned. [0]: https://news.ycombinator.com/item?id=4556125 https://news.ycombinator.com/item?id=4556125 [1]: https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810
- paulddraper 7y ago
  > which layer does TLS Transport Layer Security? Transport layer. > which layer does NAT Network Address Translation? Network layer. --- That said, the names aren't as important as the layer and independence. E.g. TLS can be used to secure any TCP traffic: STMP, HTTP, etc.
  - yzmtf2008 7y ago
    Some might argue that TLS is on Layer 6, 7 and 4 at the same time: https://security.stackexchange.com/a/93338 https://security.stackexchange.com/a/93338 Same for NAT: https://networkengineering.stackexchange.com/questions/3145/what-layer-of-the-osi-model-does-nat-work https://networkengineering.stackexchange.com/questions/3145/... > the names aren't as important as the layer and independence That's the point. Layers don't mean anything in the real world where ossifications are a thing and replacing infrastructures has a cost. There are plenty of protocols that require cross-layer coupling (aka "layering violations") and asking for layering compliance really doesn't make anyone except layering lawyers' life better.

manigandham 7y ago

Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.

kazen44 7y ago
implementing a new version of TCP would be nearly impossible because of all the equipment out in the field already. Changing transport protocol is far harder then changing IP protocol or layer 2 medium.
- manigandham 7y ago
  Why doesn't the IP protocol require new hardware if it's a lower layer?
  - watersb 7y ago
    IP doesn't require new hardware because it's a lower layer. Transmission Control Protocol - TCP - is baked into the firmware of every client network interface card, and I would suppose in almost all of the switches and routers of business infrastructure. I have no idea what data centers use. Infiniband and similar things aren't TCP, I think.
    - lizknope 7y ago
      Infiniband is a lower level than TCP. Infiniband is often used as a replacement for ethernet in a supercomputing cluster. If you wish you can run IP over Infiniband (IPoIB) but I think most people using Infiniband are running a lower latency protocol like RDMA https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoIB) https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoI...
    - manigandham 7y ago
      Is IP not handled by network devices and firmware? If it's just software then why don't we have IPv6 everywhere already?

baby 7y ago

It is basically TCP 2.0 implemented on top of UDP. What concerns do you have with this?

axaxs 7y ago
Well, I have a lot, but I don't want this to turn into a dissertation about why I don't like UDP for most things. The biggest red flag to me is that it is trivial to make the server send sizable packets to clients who didn't ask for them nor want them. Spoofing is not a solved problem, no matter how many times people scream at providers to block it before it gets out. Why isn't there a minimal ACK process up front? I mean, this thing is designed such that it's vulnerable to reflection attacks on -day 1-.
- baby 7y ago
  UDP is a 4-page RFC that is pretty much a definition of IP with ports. You can easily imagine TCP as a bunch of algorithms on top of UDP. Knowing that I’m not sure what you don’t like about UDP? Amplification attacks and spoofing are taken care of by QUIC, so these are not problems at the moment.
  - axaxs 7y ago
    That's a little unfair. When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top. UDP is simple and quick, and the assumption is that there was a reason they chose that route. AFAICT, QUIC loosely defines a way to do client address validation, but it isn't required! It's worded as 'CAN' and 'MAY' in places, and places outside the spec basically hint that 'oh no! it adds another round trip'. This makes it feel totally bolted on. Why wasn't it required up front? If someone came up to me with this idea of QUIC, the -first- thing I'd tell them is to solve this problem definitively first. The idea seems sound to me, but not if you let everyone turn it off...
    - magicalhippo 7y ago
      > When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top. AFAIK it's rather common in multiplayer games to do TCP-like features over UDP, as they usually need the UDP features but also need reliable transport for some data, and it's rather tricky to do both UDP and TCP at the same time. See for example https://fabiensanglard.net/quakeSource/quakeSourceNetWork.php https://fabiensanglard.net/quakeSource/quakeSourceNetWork.ph... or https://gafferongames.com/post/reliability_ordering_and_congestion_avoidance_over_udp/ https://gafferongames.com/post/reliability_ordering_and_cong...

taf2 7y ago

Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?

axaxs 7y ago
There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records. However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflection. See, in TCP, every connection starts with a tiny three way handshake. So if you spoof the IP, the target would just get an unknown SYNACK which is tiny. It wouldn't respond, and nothing further happens. In UDP, there is no such handshake. So the target gets the entire response. So in short, DNS amplification attacks are only useful with reflection, which doesn't work over TCP.
- srj 7y ago
  QUIC addresses this, like TCP it's a connection based protocol. It's just implemented in user space on top of UDP. The server response is required to be smaller than the client hello.
- tialaramex 7y ago
  QUIC has address validation, basically if you talk back and forth with a remote party you can get yourself a token which proves you're on path (you might really be 10.20.30.40 we can't tell, but we can tell you can intercept packets for 10.20.30.40 because you received this token we sent there, maybe you're an adversary at their ISP) and you can use that token in future to prove you're still on path for 10.20.30.40, which an off-path attacker wouldn't be able to do because they can't get that token. So this lets you prevent amplification. If somebody asks a question with a long answer, but doesn't provide the token to prove they're on path, you make them go around again first, a legitimate user sees one round trip wasted to get a token but attacks don't work..

throw0101a 7y ago

> I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. They tried with SCTP and DCCP.

rstuart4133 7y ago

> DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP... Unlikely, since TCP + TLS implemented over UDP is a better description of QUIC. Neither TCP nor UDP were designed when you had to assume the internet to be a battle ground which pitted hackers, police forces, nation states against each other, and you. In such an environment it's not at all surprising to hear Comcast was attacking their own customers using bit torrent or competing video streaming by sending them fake TCP RESETS. But TLS on the other hand - that's exactly the environment TLS is designed for. They are not going to find it so each to screw with QUIC, because TLS is baked into its DNA.