... | ... | @@ -12,24 +12,27 @@ For a detailed comparison with Google's QUIC, see [[QUIC | this]] page. |
|
|
| authentication | YES | NO | YES | **YES** | YES |
|
|
|
| authorization | NO | NO | NO | **YES** | NO |
|
|
|
| delayed authentication| NO | NO | NO | **YES** | ? |
|
|
|
| perfect forward secrecy | optional* | NO | YES** | **YES** | YES*** |
|
|
|
| perfect forward secrecy | optional* | NO | YES* | **YES** | YES*** |
|
|
|
| federated authentication | NO | NO | NO | **YES** | NO |
|
|
|
| multiple authorization levels | NO | NO | NO | **YES** | NO |
|
|
|
| multistream | NO | **YES** | **YES** | **YES** | **YES** |
|
|
|
| [Multicast](Multicast) support| NO | NO | NO | **YES** | NO |
|
|
|
| reliable transmission | YES | YES | YES | YES | YES |
|
|
|
| unreliable transmission | NO | **YES** | NO | **YES** | NO (?) |
|
|
|
| unreliable transmission | NO | **YES** | NO* * | **YES** | NO (?) |
|
|
|
| byte-stream communication | YES | YES | YES | YES | NO |
|
|
|
| datagram communication | NO | **YES** | NO | **YES** | YES (RPC) |
|
|
|
| header length (for data) | 38 (+options)| 32 | ?45+?(including UDP) | **~29** (including UDP)| 52(with UDP) |
|
|
|
| header length (for data) | 38 (+options)| 32 | 9-45+?(including UDP)* * * * | **~29** (including UDP)| 52(with UDP) |
|
|
|
| stun support for clients | NO | NO | NO | **Planned** | NO |
|
|
|
| protocol-level [proxy](Proxy)| NO | NO | NO | **Planned** | NO |
|
|
|
| Feature | TLS (TCP) | SCTP | QUIC | Fenrir | MinimaLT |
|
|
|
|
|
|
----
|
|
|
* Perfect forward secrecy (PFS) must be explicitly enabled with proper algorithm support in TLS. QUIC provides PFS, but only after the connection setup, and the key for the initial authentication and key exchange is not connection-specific, but is regenerated every couple of minutes. This setup is not perfect but permits QUIC to avoid one RTT and as long as the interval between key regeneration is not long it can be considered secure.
|
|
|
\* Perfect forward secrecy (PFS) must be explicitly enabled with proper algorithm support in TLS. QUIC provides PFS, but only after the connection setup, and the key for the initial authentication and key exchange is not connection-specific, but is regenerated every couple of minutes. This setup is not perfect but permits QUIC to avoid one RTT and as long as the interval between key regeneration is not long it can be considered secure.
|
|
|
|
|
|
** QUIC can be hacked to do unreliable transmission by sending data in a new stream and then forgetting about that stream instead of tracking it. It does not support data spanning multiple packets or maintaining the same stream ID.
|
|
|
|
|
|
***minimaLT perfect forward secrecy is not per-connection, and requires server and dns collaboration. See the [MinimaLT](MinimaLT) page for details.
|
|
|
|
|
|
\*\*\*\* QUIC header is extremely flexible, and can range from 9 bytes up to almost 60 depending on the status of the connection on both the server and client side.
|
|
|
|
|
|
---- |
|
|
\ No newline at end of file |