Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

71–80 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#71
post #23

Earlier quoted context omitted.

Do keep in mind that "want" isn't exactly accurate. No IT team wants to spend any time/effort maintaining that crap, the business doesn't want to shell out for it either since it's expensive, and the ops team doesn't want yet another thing mucking with traffic. Yet we have one because it's required by law. Wanna take a guess at what companies make sure it stays required by law?

Please tell me what law applies to most companies that do this?

You won't find specific laws.

The laws (in the US, at least) are typically written such that some part of the administration is deputized to promulgate technical standards and rules, most of which delegate to the NIST, but sometimes to industry bodies. Laws like this include HIPAA, FERPA, FISMA, and GLB.

There are lots of industry standards you can reference (such as the Cloud Security Alliance Common Controls Matrix), but the government will generally look at things from the perspective of NIST publications, such as NIST 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations". So, basically, what the government thinks private enterprise should be doing to comply with legal requirements to protect sensitive information.

In that document, there are a number of "controls" an organization should have in place, in particular, it should audit any and all data transfers, and ensure such transfers can be traced back to a unique user.

Even within that framework, you aren't going to necessarily find a blanket "read everyone's mail!" edict. Instead, what you are going to do, is make an assessment, as an organization, about what you think you need to do in order to withstand any potential lawsuits that may arise from any kind of disclosure.

If we made software engineers individually liable for these things the way civil and mechanical engineers are, things would look very different.

[Ed: misspelled FERPA]

Re: QUIC – Will It Replace TCP/IP?

#73
post #14

> Will It Replace TCP/IP? No. This as been another episode of "simple answers to stupid questions".

Just the title itself shows author has no idea what the hell he is talking about TCP/IP != TCP

TCP/IP refers to the entire stack that Internet is build on, the UDP is actually part of TCP/IP (it was added later for use cases where low latency was important, like telephony). He probably meant just TCP, but that's still "no".

Re: QUIC – Will It Replace TCP/IP?

#74
post #59
post #52

Nah, I think it won't. 1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense. 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement. By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Diffe…

1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ? 2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS

Why not ? Because it require a lot of CPU power... A lot.

Re: QUIC – Will It Replace TCP/IP?

#75

Earlier quoted context omitted.

It's odd you refer to endpoints as being the "more affordable place". Because running monitoring software on 5,000 PCs plus management infrastructure and software updates is a lot more "expensive" than having a single purpose-built box on the border between the network and the wider Internet. Now, I get that QUIC's developers live in a zero-trust/BeyondCorp model, and expect everyone else to too, and with COVID-19, a…

> It's odd you refer to endpoints as being the "more affordable place". The endpoints afford monitoring. The middle of the network does not afford it, so you are fighting the system and it is certain that you will break stuff.

The middle of the network has always afforded monitoring, until certain companies with a vested interest in interfering with said monitoring started pushing the Internet to not afford it.

Middleboxes are the system, and protocols that deliberately try to block inspection are fighting it and trying to break stuff.

Re: QUIC – Will It Replace TCP/IP?

#77
post #59
post #52

Nah, I think it won't. 1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense. 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement. By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Diffe…

1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ? 2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS

If everything on the Internet ends up encrypted, I will call you to troubleshoot the problematic SIP calls. ;)

eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.

Re: QUIC – Will It Replace TCP/IP?

#79
post #52

Nah, I think it won't. 1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense. 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement. By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Diffe…

The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.

Re: QUIC – Will It Replace TCP/IP?

#80
post #59

Earlier quoted context omitted.

1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ? 2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS

I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.

QUIC nicely abstracts the crypto from the transport protocol so you could easily plug in different crypto implementations. For example, someone already did a QUIC with Noise implementation.
Post reply on HN