71–80 of 116 posts
Earlier quoted context omitted.
QUIC actually requires that request packets must be larger than the responses, until a handshake has been performed, in order to prevent reflection attacks.
Do you mean larger or smaller? I thought the problem was amplification.
QUIC costs something like 2x to 4x as much CPU time to serve large files or streams per byte as compared to TCP. This is because the anti-middlebox protections also mean that modern network hardware and software offloads that greatly reduce CPU time cannot work with QUIC. When combined with the fact that QUIC is userspace, that's just deadly for performance. I'm talking about TSO, LRO (aka GRO), kTLS, and kTLS + hw e…
As far as I’ve been able to determine, QUIC suffers from the same SNI data leak that existing TLS versions with TCP has. I understand that ESNI is being (or is already?) included in the TLS 1.3 spec, but it’s obviously optional at this point. Anyways, since QUIC is being touted everywhere as being very secure: > [QUIC] protects both the data and the transport protocol itself It seems like missing ESNI as a required f…
A few people have been very vocal about not encrypting the SNI. Mostly firewall makers who obviously want to sniff it...
I'm currently working with HTTP/2 (more specifically HAS with HTTP/2 Server Push) and it's just a huge pain to find a high-level library that can help with this. I fear that it'll take even longer for HTTP/3 to be adopted or HTTP/2 might just be skipped altogether. Why are there so many server-side implementations available for a variety of languages though many still lack some features or a client-side implementatio…
Hopefully vendors like Forcepoint are trying to keep up. The first rollout of QUIC worked terribly in a lot of corporate environments because these MITM content filtering solutions didn't pay attention.
It will be interesting because it's a problem for all middleboxes that do any sort of deep packet inspection. Most of the devices that fall into this category today leverage many performance gains made by the assumption that 1) the majority of network layer traffic is TCP and 2) they have access to certain levels of metadata for free. Things are changing and getting a lot more difficult with HTTP/3 (IETF QUIC) and TL…
In my country we had many televisions labelled HD Ready when HD television first became available. Were these actually ready to play HD television? Er, no. They could however tolerate existing in a world with HD while not being HD themselves and this was what they marketed as "HD Ready".
Do you have examples where they actually do TLS 1.3?
QUIC will also usher in a new era of volumetric DDoS attacks. No longer can content providers use upstream ACLs to block udp garbage and fragments. The only option will be to use Fastly, AWS, or Cloudflare to ride out attacks. QUIC is the tool to bring about the next phase of Internet centralization by the mega players.
" TCP Fast Open is a stellar example of one such modification to TCP: eight years after it was first proposed, it is still not widely deployed, largely due to middleboxes. " Anyone remember TTCP?
Earlier quoted context omitted.
I was just browsing websites that were loading unusually slowly, so did the usual ping/mtr to investigate, which pointed to the router. From there and a bit of tcpdumping the cause turned out to be UDP traffic to Google from another person, who was watching videos I think.
your router shouldn't introduce noticable latency. If it does it either has a weak CPU or network queues that are too large. In the former case you need to upgrade hardware, in the latter you need a firmware that supports CAKE.
Also, some routers prioritize all UDP packets because they treat them as VoIP. Then all TCP suffers.
Some service providers traffic shape UDP because uTorrent uses it (UTP) on random port numbers.
Earlier quoted context omitted.
I was just browsing websites that were loading unusually slowly, so did the usual ping/mtr to investigate, which pointed to the router. From there and a bit of tcpdumping the cause turned out to be UDP traffic to Google from another person, who was watching videos I think.
your router shouldn't introduce noticable latency. If it does it either has a weak CPU or network queues that are too large. In the former case you need to upgrade hardware, in the latter you need a firmware that supports CAKE.
Earlier quoted context omitted.
It will be interesting because it's a problem for all middleboxes that do any sort of deep packet inspection. Most of the devices that fall into this category today leverage many performance gains made by the assumption that 1) the majority of network layer traffic is TCP and 2) they have access to certain levels of metadata for free. Things are changing and getting a lot more difficult with HTTP/3 (IETF QUIC) and TL…
In the cases I've noticed the middlebox vendor claims TLS 1.3 only meaning that now their product isn't critically insecure in the face of TLS 1.3. It can't actually speak TLS 1.3 it just knows to say "Sorry, TLS 1.2 only" without breaking everything. In my country we had many televisions labelled HD Ready when HD television first became available. Were these actually ready to play HD television? Er, no. They could h…
HN discussion here: https://news.ycombinator.com/item?id=16564935