Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
F
Fenrir_Project
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Fenrir
  • Fenrir_Project
  • Wiki
  • Comparison

Comparison

Last edited by Luker Feb 09, 2018
Page history

Comparison

This is just a quick table-comparison between the protocols TLS, SCTP, QUIC

For a detailed comparison with Googles QUIC, see this page.


Feature TLS (TCP) SCTP QUIC Fenrir MinimaLT
encryption YES NO YES YES YES
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***
federated authentication NO NO NO YES NO
multiple authorization levels NO NO NO YES NO
multistream NO YES YES YES YES
Multicast support NO NO NO YES NO
reliable transmission YES YES YES YES YES
unreliable transmission NO YES NO* * YES NO (?)
byte-stream communication YES YES YES YES NO
datagram communication NO YES NO YES YES (RPC)
Forward Error Correction NO NO NO YES NO
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 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.

** QUIC currently does not support unreliable transmission, but there is an ietf draft for the support

***minimaLT perfect forward secrecy is not per-connection, and requires server and dns collaboration. See the 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.


Clone repository
  • Auth_Details
  • CLA
  • Comparison
  • Current_Auth_Schemes
  • DNSSEC_Details
  • Development
  • Federated_vs_Distributed
  • Federation_Details
  • Luca_Fulchir
  • Multicast
  • OAuth_Hate
  • Packet_Structure
  • Paper
  • Proxy
  • QUIC
View All Pages