You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chiradeep Vittal <Ch...@citrix.com> on 2012/07/02 21:48:33 UTC
site-to-site VPN review
I took another look at the FS
http://wiki.cloudstack.org/display/DesignDocs/Site-to-site+VPN+functional+spec
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 ?
2. Why is this restricted to admin only?
3. Does this require "conserve mode = true" ?
4. Is NAT traversal supported?
5. FS and test suite in my mind should cover FCAPS (faults, configuration, administration, performance, security)
* How do you deal with faults? What happens when the VR is restarted? What happens if VR gets disconnected from the remote end?
* The API parameters and responses need to be more completely documented.
* 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?
* How well does this perform: what is the target throughput and what is the size (RAM/CPU) needed to achieve this performance?
* Is there a need for a later kernel on the VR for AES support?
* How secure is this implementation? Can the PSK be guessed? Are the latest security patches for OpenSwan available in the VR?
Re: site-to-site VPN review
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Jul 2, 2012 at 3:06 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
>
>
> On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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
>
Re: site-to-site VPN review
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Jul 2, 2012 at 3:09 PM, Chiradeep Vittal
<Ch...@citrix.com> 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" <Ch...@citrix.com> wrote:
>
>>
>>
>>On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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
>>
>
RE: site-to-site VPN review
Posted by Kevin Kluge <Ke...@citrix.com>.
I've heard some requests for that and I do think it would be a good feature. CloudBridge is notably different from site-site VPN though. It works at layer 2, does WAN optimization, and requires CloudBridge at both ends of the connection.
-kevin
> -----Original Message-----
> From: Clement Chen [mailto:clement.chen@citrix.com]
> Sent: Monday, July 02, 2012 3:21 PM
> To: CloudStack DeveloperList
> Subject: RE: site-to-site VPN review
>
> Regarding performance, is there a plan to incorporate Netscaler's
> CloudBridge feature (basically a site-to-site VPN) ?
>
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, July 02, 2012 3:09 PM
> To: CloudStack DeveloperList
> Subject: Re: site-to-site VPN review
>
> 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" <Ch...@citrix.com> wrote:
>
> >
> >
> >On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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+functi
> >>>ona
> >>>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
> >
RE: site-to-site VPN review
Posted by Clement Chen <cl...@citrix.com>.
Regarding performance, is there a plan to incorporate Netscaler's CloudBridge feature (basically a site-to-site VPN) ?
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Monday, July 02, 2012 3:09 PM
To: CloudStack DeveloperList
Subject: Re: site-to-site VPN review
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" <Ch...@citrix.com> wrote:
>
>
>On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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+functi
>>>ona
>>>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
>
Re: site-to-site VPN review
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <Ch...@citrix.com> wrote:
>
>
>On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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
>
Re: site-to-site VPN review
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 7/2/12 2:33 PM, "Sheng Yang" <sh...@yasker.org> 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.
>
>> 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
Re: site-to-site VPN review
Posted by Sheng Yang <sh...@yasker.org>.
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