Page History

Feature Reference

Bug Reference

TODO

Branch

What branch is this work being done in

Introduction

Purpose

State the purpose of the document; something like: this is functional specificationS of feature "..." which has Jira ID CS-xyzw

References

• relevant links

Document History

Provide the new VPN implementation based on IKEv2 rather than using existing L2TP implementation.

Document History

v1 - Khosrow Moossavi - April 2nd 2018

...

Feature Specifications

• provide a global settings to switch between L2TP and IKEv2 (only one can be active throughout an installation)
• out of the box configuration of ipsec will be provided in /etc/ipsec.d/ikev2.conf
• authentication will be done with EAP and Public Key
• it will use self-signed certificates per domain act as CA on VRs
• PKI backend engine (out of the box support)
  • Vault by HashiCorp
  • Default internal implementation (TBD on dev@)
  • External Services (such as Let's Encrypt) (TBD on dev@)
  • Bring Your Own Certificate (BYOC) model (TBD on dev@)
• put a summary or a brief description of the feature in question 
• list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities
• list all open items or unresolved issues the developer is unable to decide about without further discussion
• quality risks (test guidelines)
  • functional
  • non functional: performance, scalability, stability, overload scenarios, etc
  • corner cases and boundary conditions
  • negative usage scenarios
• specify supportability characteristics:
  • what new logging (or at least the important one) is introduced
  • how to debug and troubleshoot
  • what are the audit events 
  • list JMX interfaces
  • graceful failure and recovery scenarios
  • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
  • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
• explain configuration characteristics:
  
  • configuration parameters or files introduced/changed
  • branding parameters or files introduced/changed
  • highlight parameters for performance tweaking
  • highlight how installation/upgrade scenarios change
• deployment requirements (fresh install vs. upgrade) if any
• system requirements: memory, CPU, desk space, etcno special requirements needed
• interoperability and compatibility requirements:
  • OS
  • xenserver, hypervisors
  • Tested on Debian 7 on VR
  • All major OSes (Linux, Windows 10, Mac X) as client of VPNstorage, networks, other
• list localization and internationalization specifications specifications
  
  • one language key added (message.enabled.vpn.ca.certificate)
• explain the impact and possible upgrade/migration solution introduced by the feature explain performance & scalability implications when feature is used from small scale to large scale
• explain security specifications
  • list your evaluation of possible security attacks against the feature and the answers in your design* *
• explain marketing specifications
• explain levels or types of users communities of this feature (e.g. admin, user, etc)

  Use cases

  put the relevant use case/stories to explain how the feature is going to be used/work

  Architecture and Design description

  ...

  • • this will be used by both infra admin, customer admin and customer user as it will be the Remove Access VPN implementation

  Architecture and Design description

  • the main feature is pretty straight forward, a global setting is added to distinguish between L2TP and IKEv2 implementation
  • the scripts changes on VR are pretty straight forward as well, the type of VPN added in the command being sent to VR and the corresponding ipsec config file will be loaded
  • the main part of the design document will be around using external or start implementing internal PKI backend engine. which we will have multiple options (at least two)
    • Using Vault as the PKI engine (recommended by author and fully implemented as of Apr 2018)
    • Using Cloudstack as a self contained PKI engine (it's not recommended and it's not implemented)
    • Using external services (such as Let's Encrypt) to generate and sign certificates (this is nice to have but will need to be discussed on ML)
    • Bring Your Own Certificate (BYOC) model (this is nice to have but will need to be discussed on ML)
  • list of added settings are

  Name	Description	Default Value
  pki.engine.certificate.brand	Brand name to be used in Certificate's common name	Cloudstack
  pki.engine.certificate.common.name	Certificate's common name template (brand will be filled from 'pki.engine.certificate.brand', domain will be provided on the fly	__BRAND__ VPN __DOMAIN__ CA
  pki.engine.vault.cca.ttl	Vault PKI root CA TTL (e.g. 87600h)	87600h
  pki.engine.vault.enabled	Enable Vault as the backend PKI engine	false
  pki.engine.vault.mount.path	Vault PKI mount point prefix (must not end with trailing slash)	pki/cloudstack
  pki.engine.vault.role.name	Vault PKI role name	cloudstack-vpn
  pki.engine.vault.role.ttl	Vault PKI role TTL (e.g. 43800h)	43800h
  pki.engine.vault.token	Token to access Vault	(empty)
  pki.engine.vault.token.role.id	App Role id to be used to fetch token to access Vault	(empty)
  pki.engine.vault.token.secret.id	Secret id to be used to fetch token to access Vault	(empty)
  pki.engine.vault.ttl	Vault PKI TTL (e.g. 87600h)	87600h
  pki.engine.vault.url	Full URL of Vault endpoint (e.g. http://127.0.0.1:8200)	http://127.0.0.1:8200

   

   

  ...

  Web Services APIs

  list changes to existing web services APIs and new APIs introduced with signatures and throughout documentation

  UI flow

  • either demonstrate it visually here or link to relevant mockups

  IP Clearance

  • what dependencies will you be adding to the project?
  • are you expecting to include any code developed outside the Apache CloudStack project?

  Usage Impact

  • Are there any entities being created that require usage reporting for billing purposes? 

  • Does this change any existing entities for which usage is being tracked already?

  Appendix

  Appendix A:

  • Added API
    • ListVpnCaCertificateCmd
      • input:
        • domain (uuid)
      • output (CertificateResponse)
        • certificate: The client certificate
        • privateKey: Private key for the certificate
        • caCertificate: The CA certificate(s)
  • Modified API
    • RemoteAccessVpnResponse: two additional fields
      • type: the type of remote access vpn implementation (e.g. l2tp or ikev2)
      • certificate: the client certificate

   

  UI flow

  • the only changes on the UI are the fact that we don't have Preshared Key anymore rather we will have Certificates (and user should be able to download them)

  IP Clearance

  • https://github.com/BetterCloud/vault-java-driver com.bettercloud.vault-java-driver (v3.1.0 for now, I might need to upgrade it to v3.1.1 soon based on an open PR I have)

  Usage Impact

  • None

  ...