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.63 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Mon, 2 Jul 2012 15:09:28 -0700
Subject: Re: site-to-site VPN review
Thread-Topic: site-to-site VPN review
Thread-Index: Ac1Yn0Cp1glNSrnWTfujay2AlK0QQQ==
Message-ID: <CC1769FD.26A74%chiradeep.vittal@citrix.com>
In-Reply-To: <CC176709.26A55%chiradeep.vittal@citrix.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

Also, if we could put out an example Cisco / Juniper configuration that is
known to work with the CloudStack site-to-site VPN, that would be great.

On 7/2/12 3:06 PM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com> wrote:

>
>
>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+functiona
>>>l
>>>+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
>