On Mon, Jul 2, 2012 at 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+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.
I can update this. > >> >>> 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. The both log files are rorated/archived. They are in the scope of standard syslog. > >> >>> * 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. Yes, and last time we tried the kernel support it and it failed... We need look into the kernel issue though. > >> >>> * 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. > Sure --Sheng >> >>--Sheng >
