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

Google is working on creating a new protocol named QUIC to replace UDP

plus.google.com

Post reply on HN
Print view View original

41–50 of 118 posts

Re: Google is working on creating a new protocol named QUIC to replace UDP

#41

Post by jbooth »

taligent wrote: post #34
dietrichepp wrote: post #30

Earlier quoted context omitted.

Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)

The Java Community Process back in the day was a good example of how lots of large companies working together could define a standard and yet still leave room for innovation. H.264 and WiFi standards are recent examples of a lot of companies working together.

Yeah, but 90% of those standards were TERRIBLE. Like, GOD AWFUL. EJB? SOAP?

It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java.

Eventually the JCP turned into "take popular open source ideas like hibernate and spring, and bless them with a JCP number". Which worked a lot better, and each of those individual projects was usually launched by an individual or small group initially.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#42

Post by latitude »

xyzzy123 wrote: post #35
latitude wrote: post #20

I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…

I agree with your original point, but none of the stuff after [EDIT] makes much sense to me. "Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet." I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption th…

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet.

More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#43

Post by exDM69 »

latitude wrote: post #20

I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…

> Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs... > So - surprise! - you have no choice but to design a TCP clone.

Some use cases don't really want TCP or a TCP clone, for example multi-player games might only use a semi-reliable loss detection system which has ACK's but does not attempt retransmission on failure to deliver. This works a lot better than TCP for that use case, and is not really a "TCP clone".

Re: Google is working on creating a new protocol named QUIC to replace UDP

#44

Post by xyzzy123 »

latitude wrote: post #42
xyzzy123 wrote: post #35

Earlier quoted context omitted.

I agree with your original point, but none of the stuff after [EDIT] makes much sense to me. "Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet." I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption th…

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet. More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.

Blind, or with some way to observe the sequence numbers?

If it's blind (e.g. window guessing) I'm interested in what your techniques are.

If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that.

Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :)

tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 16284/nc

If you can terminate it with a FIN or an RST in the next hour, I'll post proclaiming your victory. If either the box or my local link drops, we'll call it a draw.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#45

Post by taligent »

taligent wrote: post #34
dietrichepp wrote: post #30

Earlier quoted context omitted.

Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)

The Java Community Process back in the day was a good example of how lots of large companies working together could define a standard and yet still leave room for innovation. H.264 and WiFi standards are recent examples of a lot of companies working together.

jbooth: Hindsight is a wonderful thing.

The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know.

But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons standards is still pretty clear.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#46

Post by tcoppi »

xyzzy123 wrote: post #44
latitude wrote: post #42

Earlier quoted context omitted.

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet. More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.

Blind, or with some way to observe the sequence numbers? If it's blind (e.g. window guessing) I'm interested in what your techniques are. If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that. Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :) tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 1628…

There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack.

EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#47

Post by [deleted] »

latitude wrote: post #20

I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…

[deleted]

Re: Google is working on creating a new protocol named QUIC to replace UDP

#48

Post by DanWaterworth »

EwanToo wrote: post #32
DanWaterworth wrote: post #5

I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.

I think it's entirely sensible to think about the influence that companies like Google are gaining. Each individual component is a sensible step forwards, but there's no doubt that Google could choose to do some pretty anti-competitive things if they wanted, and in the future there will always be different, more short-term, management in charge

This. The point is not what they are doing, it's what they could do.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#49

Post by xyzzy123 »

tcoppi wrote: post #46
xyzzy123 wrote: post #44

Earlier quoted context omitted.

Blind, or with some way to observe the sequence numbers? If it's blind (e.g. window guessing) I'm interested in what your techniques are. If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that. Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :) tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 1628…

There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack. EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.

Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing...

Also, crap, I'm an idiot. Let me do that non-natted ;)

tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc

Re: Google is working on creating a new protocol named QUIC to replace UDP

#50

Post by xyzzy123 »

xyzzy123 wrote: post #49
tcoppi wrote: post #46

Earlier quoted context omitted.

There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack. EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.

Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc

Write failed: Broken pipe

Well done! Also, you didn't packet me off the Internet, which was nice :)

Bet you can't do it with one packet though!

Post reply on HN