Changes between Version 17 and Version 18 of RoadMap


Ignore:
Timestamp:
05/21/10 15:38:26 (14 years ago)
Author:
David Sommerseth
Comment:

Updated v3.0 comments to fit better to the new drawing

Legend:

Unmodified
Added
Removed
Modified

  • RoadMap

    v17 v18  
    6868Openvpn configuration file would define which modules to use.
    6969
    70 The SSL module could f.ex. be an OpenSSL, NSS or GNUTLS module, which handles everything which is related to certificates and encryption.
     70Thoughts about modules:
     71 * Socket module
     72   * Consider support for the SCTP protocol?  http://www.ibm.com/developerworks/linux/library/l-sctp/
     73   * For the creative minds, in theory, it could be possible to write a socket module which would send data as HTTP requests, to trick itself through strict proxies.
    7174
    72 The authentication module would somehow co-operate with the SSL module, but still being able to be used without SSL, but then enabling other types of authentication methods.
     75 * Authentication
     76   * SSL modules needs some kind of possibility to communicate to the authentication module, for client certificate authentication.  This is to avoid any authentication at all in the SSL module
     77   * The same could go for the socket module, to "authenticate" (allow/disallow) clients based on their IP address
    7378
    74 A Network protocol and routing module would look at the decrypted packets and do the proper protocol processing of the packets between the TUN/TAP device and the internal OpenVPN "network".  This is where the IPv4 and IPv6 stuff would go in.
     79 * Protocol
     80   * This module is responsible for the packets inside the tunnel only.  It needs to make sure the different supported protocol types are routed and/or filtered correctly.
    7581
    76 The logging module can log to file, syslog, a network socket, database connection - depending on the module.  If not enabled, no logging whatsoever happens.
    77 
    78 If OpenVPN is designed like this, the "OpenVPN core" needs to be completely written from scratch before we can really begin to see something happening.  This is also the part where libevent would be implemented.  This core becomes an "internal bus" where the traffic is passed between the user-space UDP/TCP socket and the kernel-space TUN/TAP device.  The rest of the work happens in the modules.
     82 * Other generic modules
     83   * A logging module will log to file, syslog, a network socket, database connection - depending on the module.  If not enabled, no logging whatsoever happens.
    7984
    8085Provided we choose to design OpenVPN as above, we'd need to do the following:
    8186
    82  * Define which types of modules OpenVPN core should support. This means modules like, encryption, authentication, networking, routing, logging, etc, etc.  Based on the task the module would have.
    83  * Define/draft the API for the core functions of each module type, and document which modules are chain-able and which are not.
    84  * Define/draft the core's internal messaging bus for passing data between each of the modules.
     87 * Define which types of modules OpenVPN core should support.  The function they have would be the category.  The drawing mentions modules as Socket, SSL, Authentication, Configuration, Compression, Protocol and Consumer/Producer.
     88 * Define/draft the API for the core functions of each module category.  It must be defined which modules are chain-able and which are not, as well as a chain order priority.
     89 * Define/draft the core's internal packet bus for passing data between each of the modules.
    8590 * Implement the core from scratch
    8691 * Rewrite the current OpenVPN 2.x parts which are interesting to pull
    8792  into OpenVPN 3.x, to use the new module API.  Then make OpenVPN 2.x
    88   make use of this API internally - without loading the code as modules.
     93  make use of this API internally - without loading the code as external modules.