4 ms·

> without having actually researched how QUIC works I have evaluated QUIC, as reliable stream protocols on UDP are something I have a professional interest in.

> without having actually researched how QUIC works I have evaluated QUIC, as reliable stream protocols on UDP are something I have a professional interest in. > QUIC is the next iteration of TCP Its not designed for that. > That it lives on top of UDP (& might ship that way) is an implementation detail due to the realities of how the Internet is built no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Thats not considering flow control, which is a whole 'nother issue. Its always a trade-off between efficiency, speed and reliability.

tialaramex 8y ago
QUIC is an encrypted protocol. If an adversary injects forged packets the AEAD tag won't match in decryption and those packets will be discarded. I would suggest an evaluation in which you completely omitted to notice the central feature of the protocol doesn't reflect well on your abilities, regardless of whether you claim it's a "professional interest".
- KaiserPro 8y ago
  encrypting the whole protocol intrinsically protects against denial of service, buffer overflows and other common mistakes how exactly? My point is this, the client is protected from a _lot_ of noise. QUIC changes this.
  - tialaramex 8y ago
    Er, no. What happened is you have no idea what you're talking about.
    - KaiserPro 8y ago
      so your saying that in TCP, a connection orientated protocol, at each hop the router/firewall/kernel is _not_ doing basic validation to see if that connection is valid, and not coming from a spurious source? The client does all this when you open socket.connect()? no, no, you're not and no, it doesn't, which is part of my point. Lots more noise will be forwarded to the client directly, after all, stateful connection management is impossible. With more noise, comes a bigger attack surface.
vlovich123 8y ago
> Its not designed for that. Yes, yes it is. I did 20% on Quic, I've talked with the engineers on it, I've read a lot of the paper, I've written some code. It's 100% intended to replace TCP as much as SCTP & other next-gen stream-oriented protocols are. It's written on top of UDP because they're dealing with the realities of public routing on the internet. > no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. This again leads me to question how much you've actually researched Quic. It does all that & more. Now it is easier to write a Quic client in user-space that misbehaves for flow control & distribute that (TCP would typically require root access). However, that's the reality of the Internet - middleboxes have ossified the ability to add new protocols. It's why SCTP & the like are non-starters even though IETF has tried to get them to work for so long. > Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Are spoofed packets validated at every hop? It would seem like memory & CPU load at backbones would be insane to keep track of all the connections flowing across it. I'm also curious how that would be possible because a backend route switch (i.e. new BGP route) would cause all middleboxes to drop the connection. I'm not sure even ISPs try to reject TCP connections early. As for the "protection" you lose (if there is any), you gain by your ability to hop physical networks without losing the connection (i.e. WiFi & cellular). This means there's all sorts of cool things you can do that simply weren't possible before; use both wifi & cellular at the same time to download the same file, seamless handoff of a video chat without requiring any ISP support, seamless detection & handoff of a failing internet route to a fallback connection (i.e. walking in the parking lot without having to manually switch off WiFi). The connection itself does have a connection ID in the public header in the version negotiation packet which is then mirrored in the encrypted packet header to protect against spoofing. However, the connection ID may be omitted from the public header in future packets. Anyway, I recommend reading the IETF docs on QUIC [1][2], if you have an open mind. If you just have the mentality of "UDP bad", then probably you will be wasting your own time reading it. There's lots of really smart networking experts who work on & design QUIC & lots of smart people in IETF looking over & providing feedback/criticism. I think it's safe to assume they've covered any obvious problems concerns. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-08#page-81 https://tools.ietf.org/html/draft-ietf-quic-transport-08#pag... [2] https://tools.ietf.org/id/draft-ietf-quic-manageability-01.html#rfc.section.4 https://tools.ietf.org/id/draft-ietf-quic-manageability-01.h...

tialaramex 8y ago

QUIC is an encrypted protocol. If an adversary injects forged packets the AEAD tag won't match in decryption and those packets will be discarded. I would suggest an evaluation in which you completely omitted to notice the central feature of the protocol doesn't reflect well on your abilities, regardless of whether you claim it's a "professional interest".

KaiserPro 8y ago
encrypting the whole protocol intrinsically protects against denial of service, buffer overflows and other common mistakes how exactly? My point is this, the client is protected from a _lot_ of noise. QUIC changes this.
- tialaramex 8y ago
  Er, no. What happened is you have no idea what you're talking about.
  - KaiserPro 8y ago
    so your saying that in TCP, a connection orientated protocol, at each hop the router/firewall/kernel is _not_ doing basic validation to see if that connection is valid, and not coming from a spurious source? The client does all this when you open socket.connect()? no, no, you're not and no, it doesn't, which is part of my point. Lots more noise will be forwarded to the client directly, after all, stateful connection management is impossible. With more noise, comes a bigger attack surface.

vlovich123 8y ago

> Its not designed for that. Yes, yes it is. I did 20% on Quic, I've talked with the engineers on it, I've read a lot of the paper, I've written some code. It's 100% intended to replace TCP as much as SCTP & other next-gen stream-oriented protocols are. It's written on top of UDP because they're dealing with the realities of public routing on the internet. > no, its fundamental. You can't just swap out TCP with UDP and have done with it. If we ignore the Datagram vs stream aspect, we are left with implementing our own flow control, packet loss and authentication. This again leads me to question how much you've actually researched Quic. It does all that & more. Now it is easier to write a Quic client in user-space that misbehaves for flow control & distribute that (TCP would typically require root access). However, that's the reality of the Internet - middleboxes have ossified the ability to add new protocols. It's why SCTP & the like are non-starters even though IETF has tried to get them to work for so long. > Which is where my comment comes in, with a TCP socket, if someone tries to inject spoofed packets, (assuming we in a non-LAN environment) those packets will be rejected long before they reach us. In UDP no such guarantees exist. Are spoofed packets validated at every hop? It would seem like memory & CPU load at backbones would be insane to keep track of all the connections flowing across it. I'm also curious how that would be possible because a backend route switch (i.e. new BGP route) would cause all middleboxes to drop the connection. I'm not sure even ISPs try to reject TCP connections early. As for the "protection" you lose (if there is any), you gain by your ability to hop physical networks without losing the connection (i.e. WiFi & cellular). This means there's all sorts of cool things you can do that simply weren't possible before; use both wifi & cellular at the same time to download the same file, seamless handoff of a video chat without requiring any ISP support, seamless detection & handoff of a failing internet route to a fallback connection (i.e. walking in the parking lot without having to manually switch off WiFi). The connection itself does have a connection ID in the public header in the version negotiation packet which is then mirrored in the encrypted packet header to protect against spoofing. However, the connection ID may be omitted from the public header in future packets. Anyway, I recommend reading the IETF docs on QUIC [1][2], if you have an open mind. If you just have the mentality of "UDP bad", then probably you will be wasting your own time reading it. There's lots of really smart networking experts who work on & design QUIC & lots of smart people in IETF looking over & providing feedback/criticism. I think it's safe to assume they've covered any obvious problems concerns. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-08#page-81 https://tools.ietf.org/html/draft-ietf-quic-transport-08#pag... [2] https://tools.ietf.org/id/draft-ietf-quic-manageability-01.html#rfc.section.4 https://tools.ietf.org/id/draft-ietf-quic-manageability-01.h...