Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D1D65CFB2 for ; Mon, 2 Jul 2012 21:33:48 +0000 (UTC) Received: (qmail 62166 invoked by uid 500); 2 Jul 2012 21:33:48 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 62117 invoked by uid 500); 2 Jul 2012 21:33:48 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 62109 invoked by uid 99); 2 Jul 2012 21:33:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 21:33:48 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.160.47] (HELO mail-pb0-f47.google.com) (209.85.160.47) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 21:33:40 +0000 Received: by pbbrq2 with SMTP id rq2so7986517pbb.6 for ; Mon, 02 Jul 2012 14:33:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=ecv3vF4bjpg6O3yDEljyoj2QaClmVi1g6Go5DBOcrNg=; b=erTLJk/CqhrnrD8T1ZQS2clfTBODv/e/4HBgp3is6PGQZtZKlXv3RpXyRoJogarHRT oBM7qWED8TgKJAh5XBz9CPiQTo1sC3ydIwD3Ka9kQnw/8lk+1Ri8nfI6P8EXYHK37yll s3Ig62jjpD93x8NLoq4fF3T+wBDUYD4aXDZzTOnH1uLmnRtm4zIHnALSihhGK4pyDWl3 JhKcu4Gt936EjWXqeW3q8McrrpXl0qCC9FBCyzSYXFIGfH5K8S95QcqjeCpWPZPolrVx RZxmKFNv4lDcMZdhTa3Xu2lgx3g9aSDb3LQIqLmF7nqY1NJkrdSad+ry2uDMvBpuRIa8 NNAA== MIME-Version: 1.0 Received: by 10.68.136.68 with SMTP id py4mr1507513pbb.151.1341264799456; Mon, 02 Jul 2012 14:33:19 -0700 (PDT) Received: by 10.68.72.72 with HTTP; Mon, 2 Jul 2012 14:33:19 -0700 (PDT) X-Originating-IP: [63.110.51.11] In-Reply-To: References: Date: Mon, 2 Jul 2012 14:33:19 -0700 Message-ID: Subject: Re: site-to-site VPN review From: Sheng Yang To: cloudstack-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkYCphaC6IKrVdnLQnkYHY5eKx8vG+veVce5kswe0zYANaLTaOPC3+dmDLv7Ise3ux3mbOF On Monday, July 02, 2012 12:48:33 PM Chiradeep Vittal wrote: > I took another look at the FS > http://wiki.cloudstack.org/display/DesignDocs/Site-to-site+VPN+functional+sp > ec And the test suite > http://wiki.cloudstack.org/display/QA/Site-to-Site+VPN > > > 1. It isn't clear if we are going to use pre-shared keys (PSK) or > public-key (RSA keys) * If PSK, who generates this and what is the > strength of this key? * Can this PSK be changed / revoked ? We're using PSK. Currently user generate the psk key and program it on the both side of VPN. Update the spec. > 2. Why is this restricted to admin only? Currently only admin can create/delete private gateway and vpn gateway of VPC. Though Alena just update me that he/she can do it on behavior of other account. > 3. Does this require "conserve mode = true" ? Currently we only support VPC, so it's no conserve mode here. I think even in the future when we support isolated guest network, this wouldn't be an restriction. > 4. Is NAT traversal supported? Yes. I enabled it in openswan configuration. > 5. FS and test suite in my mind should cover FCAPS (faults, configuration, > administration, performance, security) * How do you deal with faults? DPD would try to keep it recover and connected. > What happens when the VR is restarted? Currently we didn't restart VPN connection automatically. I would fix that. > What happens if VR gets disconnected from the remote end? DPD would try to recover it. I've set a 3 time retry for initial connection, but not sure about how many time it would retry in the disconnection after that. > * The API parameters and responses need to be more > completely documented. Sure. > * If a user complains that his s-2-s VPN is not > working / used to work but does not now, how can customer support diagnose > this problem? Log is in the /var/log/auth.log and /var/log/daemon.log. I didn't pull it out to separate files because openswan separate log output lacks of timestamp. > * How well does this perform: what is the target throughput > and what is the size (RAM/CPU) needed to achieve this performance? Not tested yet. > * Is there a need for a later kernel on the VR for AES support? No. AES can be done by software as well. > * How secure > is this implementation? Can the PSK be guessed? Are the latest security > patches for OpenSwan available in the VR? The level of security is the same as normal site to site implementation. So it depends on PSK to be generated. Since we didn't generated it, user controls it. For the security upgrade, it would be a common issue rather than vpn specified. We lack of up-to-date security upgrade mechanism. I suppose it's should in the plan. --Sheng