Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Mon, 2 Jul 2012 15:06:44 -0700
Subject: Re: site-to-site VPN review
Thread-Topic: site-to-site VPN review
Thread-Index: Ac1Ynt8HUaeK0HduQbKIDwY559lNqQ==
Message-ID: <CC176709.26A55%chiradeep.vittal@citrix.com>
In-Reply-To: 
 <CA+2rt42ix61bm6mN+h9UYa+B_W1wTK-YETbKnAgaot-PVGVcuw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 7/2/12 2:33 PM, "Sheng Yang" <sheng@yasker.org> wrote:

>On Monday, July 02, 2012 12:48:33 PM Chiradeep Vittal wrote:
>> I took another look at the FS
>>=20
>>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.

The Remote Access Vpn service generates the PSK on the user's behalf. This
makes it easier for the cloud admin to enforce key strength.
This is also the way AWS VPC works.

>
>>  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 =3D 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.

Can we think of a better way? Are these logs being rotated / archived? I
think the former is, not sure about the latter.

>
>> *   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.

What I mean is: take advantage of acceleration offered by Intel chips that
implement the AES-NI instruction. It is my understanding that the current
bits of the VR are unable to do this.

>
>> *   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.

My point is that when the feature is released, there shouldn't be any
known security issues with the software and it should be patched to the
latest level. Of course, future security issues is a different question.

>
>--Sheng