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
  • Requirements

Requirements

Last edited by Luker Apr 03, 2016
Page history

Requirements

After some time, I managed to write this list of requirements for Fenrir:

  • Efficiency: The protocol must not be above the 5th layer of the ISO/OSI pile and must be a binary one -- no XML.
  • Completeness: The protocol must handle authentication, authorization, encryption of the connection.
  • Flexibility: It must be adaptable to multiple needs:
    • multiple streams
    • both reliable and _unreliable connections
    • both ordered and unordered messages
    • both bytestream and datagram transmission
    • any combination of the above
    • Forward Eror Correction support
  • Interoperbility: A developer must be able to use a single library for multiple vendors, without any change (f**k OAuth).
  • Federation: As in kerberos, federated authentication must be possible.
  • Token-based: We don't like to give our password away too often.
  • Nonce-based: I really don't like to keep synchronized clocks between client and server...
  • Securely desinged: The protocol must not have any amplification attack. and provide formal proofs.
  • multiple authorization levels. We'd like to grant different levels of privilege to different applications.

These are just the main requirements. A lot of other small but important stuff is:

  • Reconnect Without big handshakes: - tcp handshake + ssl handshake + OAuth handshake takes a LOT of time, being able to associate once and then reuse the association even after a quick network failure is a good thing.
  • Multi-homing support: Possibly dynamic for long connections and mobile clients.
  • Mobility support: the connection stays up even if we change IPs.
  • Do something about the ridiculous X.509 certificate situation.

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