QUIC.md

@@ -2,7 +2,7 @@
 
 Google's QUIC is a very interesting and recent protocol. You can find its code in chromium, there's no external library...
 
-You can find some of its features summarized [here](http://www.riskcompletefailure.com/2013/08/quic-notes-stream-multiplexing-and.html) and [here](http://www.riskcompletefailure.com/2013/07/quic-notes-rational-fec-and-head-of.html), and a tentative [RFC](https://datatracker.ietf.org/doc/draft-tsvwg-quic-protocol/)
+You can find some of its features summarized [here](http://www.riskcompletefailure.com/2013/08/quic-notes-stream-multiplexing-and.html) and [here](http://www.riskcompletefailure.com/2013/07/quic-notes-rational-fec-and-head-of.html), and there's a tentative [RFC](https://datatracker.ietf.org/doc/draft-tsvwg-quic-protocol/)
 
 There is also an introductory video (nothing advanced ~51m) on [youtube](http://www.youtube.com/watch?v=hQZ-0mXFmk8)
 
@@ -16,17 +16,22 @@ Here we will look at the main differences between QUIC and Fenrir
 
 The main selling point of QUIC is that it reduces latency and messages needed to setup the connection or to manage it.
 
-This is true, as compared to TCP QUIC does a lot more work with much less overhead. TCP also has the well known [slow start](http://en.wikipedia.org/wiki/Slow-start problem).
+This is true, as compared to TCP+TLS QUIC does a lot more work with much less overhead. TCP also has the well known [slow start](http://en.wikipedia.org/wiki/Slow-start problem).
 
 There are TCP options that we can use to avoid this problem, but they make the TCP header bigger and are not a requirement for the implementation.
 
 Fenrir Tries to do the same as QUIC in regard to the number of packets required to manage a session, but extends the same concept to encryption and authentication.
 
+The main difference in general is that **QUIC seems to be a way to bring TLS to a lower level, while focusing on latency, while in Fenrir we focus a lot more on security and flexibility.**
+
 ### packet size
 
 By having integrated encryption and authentication we don't need redundant identifiers for the connection, and can optimize the packet structure as a whole.
 
-The result is that you can send encrypted and authenticated messages with Fenrir in just about 28 bytes. QUIC can take up to 45 bytes.
+The result is that you can send encrypted and authenticated messages with Fenrir in just about 30 bytes. QUIC can take up to 45 bytes.
+
+The packet structure is not extremely different, but the way it's handled in the protocol differs greatly:
+in QUIC all multiplexed streams are ordered, reliable streams, while in Fenrir you can choose any combination of (un)reliable, (un)ordered delivery, both stream and datagram.
 
 ### RTT needed
 
@@ -34,9 +39,15 @@ The connection setup is a 4-way handshake with cookies to avoid SYN flood attack
 
 QUIC supports a 0-RTT reconnection. Fenrir does not do less than 1-RTT by design. But maintaining long timeouts for the connections will have the same result. 0-RTT connections are avoided in Fenrir as they leave way too many options for amplification attacks.
 
+Here we can see what we meant before by "latency vs security". To reduce latency QUIC does neither a full PFS (next section), or have a full protection against replay attacks. As you can read in the [QUIC Crypto](https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit) document:
+
+> QUIC doesn’t provide replay protection for the client’s data prior to the server’s first reply.  It’s up the application to ensure that any such information is safe if replayed by an attacker.
+
+This is the same old mistake of pushing security details on the developers. It will likely never happen.
+
 Fenrir is actually a federated authentication protocol, so things are a little more complex, and the first time we authenticate into a federated server we might actually get up to 4 RTTs. 3 RTTs are the norm after the client has its authentication data signed for its domain.
 
-Both QUIC and Fenrir use an id for the connection. This also means that both protocols have automatically enabled multi-homing features and support mobile devices.
+Both QUIC and Fenrir use an id for the connection. This also means that both protocols have automatically enabled multi-homing features and support mobile devices. It is unclear how QUIC handles those, though. Given their use of the "entropy bit" it is likely that multihoming and mobility can not be used.
 
 
 ## Perfect forward secrecy
@@ -47,6 +58,9 @@ This enables QUIC to have one RTT less then Fenrir, but the connection is not to
 
 As long as the ephemeral public key is changed quickly (let's say, every couple of hours at most) this seems a good idea, and Fenrir implements it with the Stateful handshake.
 
+An other example of latency vs security. To decrease latency, the initial data sent by the client is NOT protected by PFS. Instead, PFS is set up at the first packet sent by the server. The client can, however, still
+send non-PFS data in this period of time.
+
 ### PFS on resumed connections
 
 QUIC simply tries to guess that the last public key used is still in use, so it hopes for a 0-RTT reconnection, and has a fallback to 1-RTT reconnection.
@@ -55,7 +69,7 @@ Connection resumption is not a thing in Fenrir, as we just need to give longer t
 
 ## Forward Error Correction
 
-This is a nice improvement of QUIC over previous protocols:
+This is a very nice improvement of QUIC over previous protocols:
 
 Basically every 2 packets we send an other packet which is the XOR of the previous 2. So if one was lost, the receiver can reconstruct it without asking a retransmission.
 
@@ -65,29 +79,30 @@ This is actually a good idea, and I decided to copy it and put it into Fenrir. H
 
 Both QUIC and Fenrir have a variable number of streams to be used in a connection, and both use a 32-bit connection identifier at the beginning of the packet. (in QUIC the id length is actually variable)
 
-QUIC stream identifiers are actually larger (32 bits) then Fenrir's (16 bits), but really, today's applications use just one stream (TCP) for everything, 65534 streams should be enough...
+QUIC stream identifiers are actually larger (32 bits) then Fenrir's (16 bits), but really, today's applications use just one stream (TCP) for everything, 65534 streams should be enough. Even assuming it is not enough, introducing an other multiplexing layer before the application is trivial.
 
-QUIC uses a 64-bit sequence number for its streams, while Fenrir has a 30-bit one, like extended TCP. Having a bigger sequence number is actually a good thing, as it helps a lot in low-latency -high bandwidth connections, such as satellite ones, but 30 bit should be enough for everybody (and 64k of ram, too...)
+QUIC uses a 64-bit sequence number for its streams, while Fenrir has a 30-bit one, like extended TCP. Having a bigger sequence number is actually a good thing, as it helps a lot in high-latency-high bandwidth connections, such as satellite ones, but 30 bit should be enough for everybody. Putting together the stream multiplexing and the 30-bit counter already lets us have connections in the range of the Tb/s for satellite connections.
 
 ### Limitations?
 
 This has some limitations, however. It means that if we use a 30-bit offset we can't send more than 1Gb of data without an acknowledgment.
 
-1Gb should be enough, as it means that the sender has to saturate a 10Gbit connection while the receiver can not send even one packet per second. As this situation seems a little extreme, I don't think it makes much sense to support it.
+1Gb should be enough, as it means that the sender has to saturate a Gbit connection while the receiver can not send even one packet per second. As this situation seems a little extreme, I don't think it makes much sense to support it.
 
 Does this means that the maximum message size will be 2^30 = 1Gb ? Not really. That is the maximum window size. But as soon as we have the initial part of the message complete, we can put it into a buffer, and wait for the rest, and we can keep doing this as many times as we want.
 
 Of course, you should not expect Fenrir to handle a multi-Gb buffer. The packet will be truncated at a certain length (user defined) and a partial message will be delivered to the user application. Big messages are usually just file transfer anyway, so chunking them does not give any problem. And do you really want Fenrir to keep a 2^64 buffer?
 
-Sequence number are specific for each stream, which means that we have 2^16 streams, with 2^30 maximum window each. That should be enough unacknowledged data...
-
 ## Proof of ownership
 
-This means that we want to be sure that the one who sent the packet is the one we think he is, and not someone else.
+This means that we want to be sure that the packet has not been spoofed.
+
+QUIC uses the usual RTT method to be sure of IP ownership, but also an other peculiar method: it makes a specific bit in the stream field random, and the two endpoints continually exchange the hash of these random bits. Which means that they have problems when a packet is dropped or lost.
 
-Aside from the authentication header, QUIC uses the usual RTT method to be sure of IP ownership, but also an other peculiar method: it makes a specific bit in the stream field random, and the two endpoints continually exchange the hash of these random bits. Which means that they have problems when a packet is dropped or lost.
+Fenrir only makes sure that at least one RTT has been done before "trusting" an ip address.
 
-Fenrir uses only an authentication header, and makes sure that at least one RTT has been done before "trusting" an ip address. The auth.header structure varies from algorithm to algorithm, but its purpose is to make sure that the sender is not a fake.
+The difference here is that QUIC tries to do continuous IP-ownership checking. This is however already present in the form of the receiving transmission window.
+The only sensible limit is a timeout on the last packet received for that IP. But the receiving window would be exhausted before the timeout anyway, so the only sensible option seems to drop an IP from the pool of the "trusted" IPs once the timeout associated with 2 receiving windows has expired.
 
 ## ACKs
 
@@ -99,7 +114,7 @@ The SCTP and Fenrir way of doing ACKs is not only to acknowledge the last stream
 
 So if we received the bytes 1...10 15...30 of a message, maybe because the 10..15 bytes were lost, we acknowledge both the 1...10 and 15...30 chunks in a single message. This should help the sender to retransmit only the part that we want, so in case of retransmission we should have a lot less duplicate packets
 
-A second, new ACK type is under development: it is based on the Forward Error Encryption idea, where we only need to know how may repair symbols the receiver needs in order to recover the lost data, without listing all the holes in the received message. This should be much more efficient, but brings some problems due to the nature of the FEC algorithm.
+A second, new ACK type is under development: it is based on the Forward Error Correction idea (see earlier section), where we only need to know how may repair symbols the receiver needs in order to recover the lost data, without listing all the holes in the received message. This should be much more efficient, but brings some problems due to the nature of the FEC algorithm, which is probabilistic.
 
 ## Congestion Control