On Mon, Jul 2, 2012 at 3:09 PM, Chiradeep Vittal
<[email protected]> wrote:
> 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.

Yes, that's already in my scope.

--Sheng
>
> On 7/2/12 3:06 PM, "Chiradeep Vittal" <[email protected]> wrote:
>
>>
>>
>>On 7/2/12 2:33 PM, "Sheng Yang" <[email protected]> wrote:
>>
>>>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+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 = 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
>>
>

Reply via email to