5 ms·

HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large m

by api 3y ago

HTTP3 doesn't have the same chicken-or-egg problem as IPv6. It runs over UDP. IPv6 is a full protocol rev which takes a lot longer to accomplish. Once a large multi-vendor network is deployed revving the base protocol is really hard.

ronsor 3y ago
Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.
- londons_explore 3y ago
  so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
- api 3y ago
  That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.
  - apitman 3y ago
    I agree, I just hope we don't see the opposite problem happen where we end up in a world where HTTP/1.1 over TCP goes away. I implemented a HTTP/1.1 server with range request support in JavaScript in a few hours last week. It's incomplete and likely rather insecure, but it works with curl and browsers. There's something important about having this ability.
    - api 3y ago
      HTTP/1.1 going away is less likely than IPv4 going away.
Spivak 3y ago
Yeah but > Palo Alto Networks recommends creating a security policy in the firewall to block the QUIC application. With the QUIC traffic getting blocked by the Firewall, the Chrome browser will fall back to using traditional TLS/SSL. Note that this will not cause the user to lose any functionality on their browser. Firewall gains better visibility and control of Google applications with or without the SSL decryption enabled. https://docs.paloaltonetworks.com/best-practices/10-2/decryption-best-practices/decryption-best-practices/deploy-ssl-decryption-using-best-practices https://docs.paloaltonetworks.com/best-practices/10-2/decryp... https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?... Fortinet also recommends blocking it. > However, due to the protocol is still in an experimental stage, it is not supported by Fortinet and causes some issues when SSL inspection profiles are needed to block specific websites or applications provided by Google itself. https://community.fortinet.com/t5/FortiGate/Technical-Note-Disabling-Blocking-QUIC-Protocol-to-force-Google/ta-p/191657?externalId=FD36529 https://community.fortinet.com/t5/FortiGate/Technical-Note-D... And given how trivial and likely udp/443 is already blocked because the only reason prior to QUIC you would be hitting udp/443 is some malware trying to get past the firewall and hoping it's open without inspection turned on you're fighting an uphill battle.
- b112 3y ago
  Is this the same Fortinet that just did a stock pump by releasing fake news stories about toothbrush DDoS attacks?: https://www.forbes.com/sites/daveywinder/2024/02/08/surprising-3-million-hacked-toothbrushes-story-goes-viral-is-it-true/?sh=fbeead26147d https://www.forbes.com/sites/daveywinder/2024/02/08/surprisi... I wonder how valid their claims are for anything, if they just make up things for press and publicity.
  - miohtama 3y ago
    Do I need a Fortinet firewall for my tooth brush?
apitman 3y ago
> IPv6 is a full protocol rev which takes a lot longer to accomplish And maybe will never happen. There are alternatives for a lot of what you get from IPv6, such as NAT (terrible but works for most people's needs) and SNI routing (I'm more bullish on this). Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful.
- bombcar 3y ago
  > Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful. There are quite a few, but people probably haven't heard of them, because either they were involved below the Internet (think: physical links) or were used for things like telephony or other interconnects. There are also other interfaces that involve communication but aren't Internet or telephone like (think things like ic2 or canbus, etc).
- dehrmann 3y ago
  If it's still not adopted more in 5-10 years, I wonder if they'll make what everyone wanted all along: IPv4 with longer addresses.
  - Thiez 3y ago
    That would be absurd. Why introduce a completely new protocol with 0 hardware or software support? Who would possibly adopt this over IPv6?
    - hot_gril 3y ago
      It would be possible to do basically this with the existing IPv6 header and much of the v6 infra. All existing IPv4 hosts get the same /32 on v6, and any NATs stay intact. On the UI side, keep the ipv4 address format like 8.8.8.8. Going to V6 is very low-risk, low-impact this way. V4 packets can even be converted to V6 and vice versa because it's the same address space at first. Once there's sufficient adoption of V6, individual network operators can break things up into /40, /48, etc if needed, which wouldn't be reachable via V4 anymore*. Back to UI, a /40 would look like 8.8.8.8.4. Unlike today's v6 which is a totally separate network with new routes and randomized addresses. It also has v6-mapped-v4 addresses, but that's different. * If you really want some more temporary compatibility, /40 would still be sorta reachable from V4 if you added a special kind of NAT that encodes the extra 8 address bits into the port number, but idk if that'd be palatable.
simiones 3y ago
Even if HTTP/3 had gone the route of registering QUIC as a new transport protocol instead of UDP, I think it would have still been at least one or two orders of magnitude easier to deploy than IPv6 was (though still much harder than going over UDP is, I'm not suggesting this was a bad choice in any way!). They would have had problems with kernel updates and with devices that make assumptions and more paranoid security policies, but they would have probably been able to convince most people to allow their packets to flow after a few years. Changing IPv6 is a much more fundamental change to the Internet as a whole.
- lxgr 3y ago
  I think assigning a new IP protocol number would have made QUIC a complete non-starter, and for almost no benefit compared to just encapsulating it in UDP. That's why WebRTC encapsulates SCTP (for data connections) in UDP, why ESP (for IPsec) is encapsulated in UDP etc. > they would have probably been able to convince most people to allow their packets to flow after a few years Looking at all these stateful NATs in network cabinets that nobody has looked at for years, I highly, highly doubt it.
deleted 3y ago
[deleted]
hot_gril 3y ago
I'm annoyed that the comment above yours dismisses the entire article based on the false assumption that QUIC is its own L4 protocol. I was fooled for a second, then I actually read the article, where it clearly says QUIC runs over UDP. So there's no chicken-and-egg.
- wmf 3y ago
  A lot of firewalls are blocking UDP and unknown L4 protocols so QUIC is blocked either way. QUIC can only work because happy eyeballs falls back to HTTP/2. UDP is definitely better for NATs since they don't know how to translate unknown protocols (e.g. SCTP).
  - hot_gril 3y ago
    Which firewalls are broadly blocking UDP? I haven't seen that on a residential router or ISP. Lots of things rely on UDP already.
    - wmf 3y ago
      Corporate firewalls tend to be much more restrictive than consumer.
      - hot_gril 3y ago
        Yeah, if it's just corporate falling back to HTTP2 (or maybe more realistically, HTTP1), then I think it's alright. Same corporate users delayed leaving unencrypted HTTP, broken versions of TLS, Windows XP, etc yet everyone else adopted anyway. They'll either follow suit eventually or work around it.

by api 3y ago

ronsor 3y ago

Not to mention the companies backing it are so large and critical they can simply mandate it and enterprises will just have to deal with it, somehow.

londons_explore 3y ago
so far, there is no reason to mandate http/3. There is barely any infrastructure cost to running a dual HTTP/1.1 and HTTP/3 setup. And the two are so similar to application developers that there is no reason to mandate anyone move over. However... It only takes one killer feature not compatible with HTTP/1.1 (eg. realtime VR with a stream per eye, and it turns out HTTP/1.1 can't do realtime bidirectional streams), and suddenly everyone will start turning off HTTP/1.1 services and replacing it with a page saying "please upgrade your web browser".
api 3y ago
That part is great. It uses UDP, which means it helps prevent UDP from being sidelined or blocked by middleboxes. That in turn helps prevent the Internet from becoming a de-facto HTTP-only network, which was a trend that was kind of happening in the 20-teens and had me concerned.
- apitman 3y ago
  I agree, I just hope we don't see the opposite problem happen where we end up in a world where HTTP/1.1 over TCP goes away. I implemented a HTTP/1.1 server with range request support in JavaScript in a few hours last week. It's incomplete and likely rather insecure, but it works with curl and browsers. There's something important about having this ability.
  - api 3y ago
    HTTP/1.1 going away is less likely than IPv4 going away.

Spivak 3y ago

Yeah but > Palo Alto Networks recommends creating a security policy in the firewall to block the QUIC application. With the QUIC traffic getting blocked by the Firewall, the Chrome browser will fall back to using traditional TLS/SSL. Note that this will not cause the user to lose any functionality on their browser. Firewall gains better visibility and control of Google applications with or without the SSL decryption enabled. https://docs.paloaltonetworks.com/best-practices/10-2/decryption-best-practices/decryption-best-practices/deploy-ssl-decryption-using-best-practices https://docs.paloaltonetworks.com/best-practices/10-2/decryp... https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?... Fortinet also recommends blocking it. > However, due to the protocol is still in an experimental stage, it is not supported by Fortinet and causes some issues when SSL inspection profiles are needed to block specific websites or applications provided by Google itself. https://community.fortinet.com/t5/FortiGate/Technical-Note-Disabling-Blocking-QUIC-Protocol-to-force-Google/ta-p/191657?externalId=FD36529 https://community.fortinet.com/t5/FortiGate/Technical-Note-D... And given how trivial and likely udp/443 is already blocked because the only reason prior to QUIC you would be hitting udp/443 is some malware trying to get past the firewall and hoping it's open without inspection turned on you're fighting an uphill battle.

b112 3y ago
Is this the same Fortinet that just did a stock pump by releasing fake news stories about toothbrush DDoS attacks?: https://www.forbes.com/sites/daveywinder/2024/02/08/surprising-3-million-hacked-toothbrushes-story-goes-viral-is-it-true/?sh=fbeead26147d https://www.forbes.com/sites/daveywinder/2024/02/08/surprisi... I wonder how valid their claims are for anything, if they just make up things for press and publicity.
- miohtama 3y ago
  Do I need a Fortinet firewall for my tooth brush?

apitman 3y ago

> IPv6 is a full protocol rev which takes a lot longer to accomplish And maybe will never happen. There are alternatives for a lot of what you get from IPv6, such as NAT (terrible but works for most people's needs) and SNI routing (I'm more bullish on this). Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful.

bombcar 3y ago
> Are there any examples of protocols that took a similarly long time to achieve adoption but eventually did saturate the market? That would be hopeful. There are quite a few, but people probably haven't heard of them, because either they were involved below the Internet (think: physical links) or were used for things like telephony or other interconnects. There are also other interfaces that involve communication but aren't Internet or telephone like (think things like ic2 or canbus, etc).
dehrmann 3y ago
If it's still not adopted more in 5-10 years, I wonder if they'll make what everyone wanted all along: IPv4 with longer addresses.
- Thiez 3y ago
  That would be absurd. Why introduce a completely new protocol with 0 hardware or software support? Who would possibly adopt this over IPv6?
  - hot_gril 3y ago
    It would be possible to do basically this with the existing IPv6 header and much of the v6 infra. All existing IPv4 hosts get the same /32 on v6, and any NATs stay intact. On the UI side, keep the ipv4 address format like 8.8.8.8. Going to V6 is very low-risk, low-impact this way. V4 packets can even be converted to V6 and vice versa because it's the same address space at first. Once there's sufficient adoption of V6, individual network operators can break things up into /40, /48, etc if needed, which wouldn't be reachable via V4 anymore*. Back to UI, a /40 would look like 8.8.8.8.4. Unlike today's v6 which is a totally separate network with new routes and randomized addresses. It also has v6-mapped-v4 addresses, but that's different. * If you really want some more temporary compatibility, /40 would still be sorta reachable from V4 if you added a special kind of NAT that encodes the extra 8 address bits into the port number, but idk if that'd be palatable.

simiones 3y ago

Even if HTTP/3 had gone the route of registering QUIC as a new transport protocol instead of UDP, I think it would have still been at least one or two orders of magnitude easier to deploy than IPv6 was (though still much harder than going over UDP is, I'm not suggesting this was a bad choice in any way!). They would have had problems with kernel updates and with devices that make assumptions and more paranoid security policies, but they would have probably been able to convince most people to allow their packets to flow after a few years. Changing IPv6 is a much more fundamental change to the Internet as a whole.

lxgr 3y ago
I think assigning a new IP protocol number would have made QUIC a complete non-starter, and for almost no benefit compared to just encapsulating it in UDP. That's why WebRTC encapsulates SCTP (for data connections) in UDP, why ESP (for IPsec) is encapsulated in UDP etc. > they would have probably been able to convince most people to allow their packets to flow after a few years Looking at all these stateful NATs in network cabinets that nobody has looked at for years, I highly, highly doubt it.

deleted 3y ago

[deleted]

hot_gril 3y ago

I'm annoyed that the comment above yours dismisses the entire article based on the false assumption that QUIC is its own L4 protocol. I was fooled for a second, then I actually read the article, where it clearly says QUIC runs over UDP. So there's no chicken-and-egg.

wmf 3y ago
A lot of firewalls are blocking UDP and unknown L4 protocols so QUIC is blocked either way. QUIC can only work because happy eyeballs falls back to HTTP/2. UDP is definitely better for NATs since they don't know how to translate unknown protocols (e.g. SCTP).
- hot_gril 3y ago
  Which firewalls are broadly blocking UDP? I haven't seen that on a residential router or ISP. Lots of things rely on UDP already.
  - wmf 3y ago
    Corporate firewalls tend to be much more restrictive than consumer.
    - hot_gril 3y ago
      Yeah, if it's just corporate falling back to HTTP2 (or maybe more realistically, HTTP1), then I think it's alright. Same corporate users delayed leaving unencrypted HTTP, broken versions of TLS, Windows XP, etc yet everyone else adopted anyway. They'll either follow suit eventually or work around it.