Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

Post reply on HN
Print view View original

101–110 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#101

Post by ocdtrekkie »

joshuamorton wrote: post #83
ocdtrekkie wrote: post #51

Earlier quoted context omitted.

My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions be…

How does the protocol Google chooses to use on its private intranet at all put pressure on the IETF to accept that protocol as a standard? The chrome argument at least sort of makes sense, but I really don't get how the network transport that literally no one but Google can see threatens IETF irrelevance.

I think you misunderstood what I was saying here. Google's control of both Chrome (client side monopoly) and Search, Gmail, etc. (server side monopoly) together under one entity is what enables Google to define Internet protocols on a broad scale regardless of what a standards body thinks.

I agree with you that how Google servers talk amongst themselves has no relevance in Internet standards.

Re: QUIC – Will It Replace TCP/IP?

#102

Post by JoshTriplett »

_vdpp wrote: post #82
marcosdumay wrote: post #21

Earlier quoted context omitted.

Well, they break TLS. That's almost as broad as breaking TCP. And it's because they want levels of control on the least affordable place. They wouldn't need to break anything if they added the supervising software to the endpoints.

Endpoint supervising isn't always an option. As more IoT devices start to use TLS connections to phone home, a network MITM may be the only way to see what they're reporting. Breaking TLS isn't just something that Big Brother would want to do. (This is assuming they aren't using pinned certs baked into their firmware, anyhow. I don't have good data on which manufacturers/devices are doing this, but somebody else migh…

If you want to reverse-engineer those devices, do that in a reverse-engineering lab; you may need to dissect the device to figure out what it's doing. Alternatively, run more open devices.

If you want to run those devices in production, put them in a separate network or VLAN where they can't see anything they don't need to see.

Re: QUIC – Will It Replace TCP/IP?

#103

Post by ocdtrekkie »

JoshTriplett wrote: post #100
ocdtrekkie wrote: post #75

Earlier quoted context omitted.

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.

Users have a vested interest in not having their connections MITMed. End-user security is not an "agenda" or a "vested interest". And portraying MITM attacks and similar security holes as "inspection" is spin. See also RFC 7258 ( https://tools.ietf.org/html/rfc7258 ), "Pervasive Monitoring is an Attack". Protocols that enable interception are broken and will be replaced with protocols that do not.

I disagree. Because when clients get phished or infected by malware that bypassed my inspection boxes, the end user was harmed. For me to buy that we shouldn't MITM for security reasons, you'd need to convince me that cloud providers on the other end were mildly successful at preventing malware, scams, and fraud.

And they're not. Google, Amazon, Microsoft, etc. have failed to keep the Internet safe. And when they fail they hide behind liability shields like Section 230. So it falls on IT staff, more often than not, to filter, block, and intercept where Big Tech has demonstrated inability to do so.

Re: QUIC – Will It Replace TCP/IP?

#105

Post by JoshTriplett »

ocdtrekkie wrote: post #103
JoshTriplett wrote: post #100

Earlier quoted context omitted.

Users have a vested interest in not having their connections MITMed. End-user security is not an "agenda" or a "vested interest". And portraying MITM attacks and similar security holes as "inspection" is spin. See also RFC 7258 ( https://tools.ietf.org/html/rfc7258 ), "Pervasive Monitoring is an Attack". Protocols that enable interception are broken and will be replaced with protocols that do not.

I disagree. Because when clients get phished or infected by malware that bypassed my inspection boxes, the end user was harmed. For me to buy that we shouldn't MITM for security reasons, you'd need to convince me that cloud providers on the other end were mildly successful at preventing malware, scams, and fraud. And they're not. Google, Amazon, Microsoft, etc. have failed to keep the Internet safe. And when they fai…

TLS is now pervasive. Certificate Transparency prevents CAs from aiding interception. http is now explicitly flagged as "insecure". Browser vendors have had a major part in those improvements to Internet security. (So have many other parties, such as Let's Encrypt for removing cost as an excuse for not using TLS.)

People trying to make protocols more secure don't need to convince you, they just need to make your job as hard as possible until most users reject what you're offering.

We need a dozen more ideas like Certificate Transparency. We need pervasive end-to-end DNS security, with unencrypted DNS flagged as insecure. We need a means of preventing DNS servers from altering the DNS records of sites they aren't authoritative for. We need browsers to all agree to explicitly flag connections as insecure when they chain to a locally installed certificate, in a way that can't be hidden without rebuilding from source.

And this isn't a purely technical problem, either. We also need legal support to review regulations in certain regulated industries and demonstrate well-supported ways to fulfill those regulations without breaking security (e.g. "if you do XYZ to log the time and endpoints of connections but don't actually MITM their traffic, it's reasonably well-established that you're fulfilling ABC regulation"). We need lobbyists to change regulations incompatible with secure protocols. We need designers to make security as usable as possible, because poor usability is a security problem.

Re: QUIC – Will It Replace TCP/IP?

#106

Post by coder543 »

takeda wrote: post #96
coder543 wrote: post #56

Earlier quoted context omitted.

> Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines? What's that quote about throwing stones while living in glass houses? The headline says nothing about replacing IP. It's talking about replacing "TCP/IP", which is neither "TCP or IP" nor "TCP and IP". In this case, it's asking whether TCP/IP will be replaced with a protocol (QUIC) that is built on UDP/IP. IP is…

TCP/IP != TCP TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of. If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about. [1] https://en.wikipedia.org/wiki/Internet_protocol_suite

That's not the singular definition of TCP/IP, as you're seemingly so intent on believing.

TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically.

Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and I both normally define it.[2] Cloudflare also (logically) refers to UDP/IP as a concept,[3][4] which further supports the notion that TCP/IP is not singularly referring to the whole internet protocol suite.

I understand that people do sometimes use TCP/IP to refer to the internet protocol suite as a whole, including UDP. I've seen it before. That doesn't make it the only (or most logical) definition of the term. It's certainly not the definition the authors of this webinar intended you to use when reading the title.

In the tech world, many terms are overloaded with multiple definitions. This isn’t an uncommon situation by any means.

> this title makes me believe the author doesn't know what he is talking about

Because the authors are choosing to use a different common definition of TCP/IP, you think they're the ignorant ones because you don't know that common definition? Or because you're only willing to read the title in the way that makes it seem the most nonsensical?

I left my first reply because the author of that comment was being so unnecessarily insulting to the authors, and now you're following up with similar snark, and posting it in multiple places on this topic, when there is no evidence to support that your use of the term is the only valid use of the term.

[1]: https://superuser.com/questions/449703/must-tcp-use-ip

[2]: https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/

[3]: https://www.cloudflare.com/learning/ddos/glossary/user-datag...

[4]: https://www.cloudflare.com/learning/ddos/glossary/internet-p...

Re: QUIC – Will It Replace TCP/IP?

#107

Post by marcosdumay »

ocdtrekkie wrote: post #75
marcosdumay wrote: post #67

Earlier quoted context omitted.

> 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.

Hum... The status quo is a very obvious consequence of Math. Cryptography is relatively easy, while endpoint security is a botomless pit of despair.

Re: QUIC – Will It Replace TCP/IP?

#108

Post by emmelaich »

takeda wrote: post #73
_jal wrote: 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".

TCP/IP metonymically refers to IP.

My guess is that just saying "IP" is too short.

(And ambiguous - tee hee)

Re: QUIC – Will It Replace TCP/IP?

#109

Post by Rusky »

crazygringo wrote: post #93

Better framing: Will it replace HTTPS over TCP? Maybe. Mostly. Eventually. (Hopefully?) Will it replace TCP for other purposes? Of course not.

QUIC no longer includes HTTP, so "of course not" is a bit strong. It's easily applicable to a lot more scenarios than HTTPS over TCP.

Re: QUIC – Will It Replace TCP/IP?

#110

Post by anfilt »

The one thing I like about QUIC being more wide spread is that it is making network operators treat UDP traffic more fairly.

However, I don't see it replacing TCP, and if anything it's just an other tool to use.

Post reply on HN