<div dir="ltr"><div>Hi,</div><div><br></div>I was curious to know how strongswan was playing with namespaces, so I made some test to figure out how it would work in a quantum router.<div><br></div><div>Great news is that Strongswann seems to work well when started in a namespace: daemons open socket in the netns, and IPsec SAs & SPDs are set up in the router netns and non visible in root namespace.</div>
<div><br></div><div>Bad one is that pid files location are hard coded in strongswan, as a result, it's not trivial to start multiple daemons (like charon and pluto) in different namespaces, here is the only (ugly) workaround I found so far:</div>
<div><br></div><div style>#set up IPsec connection between two router namespaces on the same host:</div><div style><br></div><div><div>ip netns add moon</div><div>ip netns add sun</div><div>ip link add veth-sun type veth peer name veth-moon</div>
<div>ip link set veth-sun netns sun</div><div>ip link set veth-moon netns moon</div><div><br></div><div>ip netns exec moon ip addr add <a href="http://192.168.1.1/24" target="_blank">192.168.1.1/24</a> dev veth-moon</div>
<div>ip netns exec moon ip addr add <a href="http://10.1.0.1/8" target="_blank">10.1.0.1/8</a> dev veth-moon</div><div>ip netns exec moon ip link set veth-moon up</div><div>ip netns exec moon ip link set lo up</div><div><br>
</div><div>ip netns exec sun ip addr add <a href="http://192.168.1.2/24" target="_blank">192.168.1.2/24</a> dev veth-sun</div><div>ip netns exec sun ip addr add <a href="http://10.2.0.1/8" target="_blank">10.2.0.1/8</a> dev veth-sun</div>
<div>ip netns exec sun ip link set veth-sun up</div><div>ip netns exec sun ip link set lo up</div><div><br></div><div>ip netns exec moon ipsec start</div><div>ip netns exec moon ipsec up moon-sun &</div><div><br></div>
<div style>#here comes the uggly part:</div><div style>rm /var/run/charon.pid <br></div><div>rm /var/run/pluto.pid </div><div>rm /var/run/starter.pid </div><div><br></div><div>ip netns exec sun ipsec start</div><div>ip netns exec sun ipsec up sun-moon &</div>
</div><div><br></div><div style>The correponding ipsec.conf</div><div><br></div><div><div>config setup</div><div> charonstart=yes<br></div><div> plutostart=yes</div><div><br></div><div>conn %default</div><div>
ikelifetime=60m</div><div> keylife=20m</div><div> rekeymargin=3m</div><div> keyingtries=1</div><div> authby=secret</div><div> keyexchange=ikev2</div><div> mobike=no</div><div>
<br></div><div>conn moon-sun</div><div> left=192.168.1.1</div><div> leftsubnet=<a href="http://10.1.0.0/16" target="_blank">10.1.0.0/16</a></div><div> leftid=@<a href="http://moon.strongswan.org/" target="_blank">moon.strongswan.org</a></div>
<div> leftfirewall=yes</div><div> right=192.168.1.2</div><div> rightsubnet=<a href="http://10.2.0.0/16" target="_blank">10.2.0.0/16</a></div><div> rightid=@<a href="http://sun.strongswan.org/" target="_blank">sun.strongswan.org</a></div>
<div> auto=add</div><div><br></div><div>conn sun-moon</div><div> left=192.168.1.2</div><div> leftsubnet=<a href="http://10.2.0.0/16" target="_blank">10.2.0.0/16</a></div><div> leftid=@<a href="http://moon.strongswan.org/" target="_blank">moon.strongswan.org</a></div>
<div> leftfirewall=yes</div><div> right=192.168.1.1</div><div> rightsubnet=<a href="http://10.1.0.0/16" target="_blank">10.1.0.0/16</a></div><div> rightid=@<a href="http://sun.strongswan.org/" target="_blank">sun.strongswan.org</a></div>
<div> auto=add</div></div><div><br></div><div>Any thoughts on that?<br></div><div><br></div><div style>Francois.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/17 Qin Li <span dir="ltr"><<a href="mailto:qili@vmware.com" target="_blank">qili@vmware.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+ one more comment for 3. Local_cidrs<br>
If there are there subnets got from "subnet_id" and user only wish to<br>
provide VPN tunnel access to two of them from remote, we need to keep<br>
local_cidrs.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Qin<br>
</font></span><div class="im HOEnZb"><br>
-----Original Message-----<br>
From: Qin Li [mailto:<a href="mailto:qili@vmware.com">qili@vmware.com</a>]<br>
</div><div class="im HOEnZb">Sent: 2013年5月17日 9:55<br>
To: OpenStack Development Mailing List<br>
</div><div class="HOEnZb"><div class="h5">Subject: RE: [openstack-dev] VPNaaS<br>
<br>
For design on <a href="https://wiki.openstack.org/wiki/Quantum/VPNaaS" target="_blank">https://wiki.openstack.org/wiki/Quantum/VPNaaS</a> , I'd like to<br>
share some of my comments.<br>
<br>
1. Table IKEPolicy<br>
a. encryption_algorithm, please include more information about algorithm<br>
such as cipher mode. The value could be 3des-192-cbc, aes-128-cbc,<br>
aes-192-cbc, aes-256-cbc, aes-128-gcm-a, aes-256-gcm-a, aes-128-ccm etc.<br>
So as to support more kinds of cipher modes.<br>
b. phase1_negotiation_mode, suggest to rename it as phrase1_mode or mode,<br>
phrase 1 already contains the meaning "negotiation".<br>
c. pfs, since there is no pfs_enable flag, null value of pfs means<br>
disabled. What does it mean if user does not specify it in inputs?<br>
d. A minor adjustment suggestion for encryption_algorithm and<br>
auth_algorithm, we could combine them into a phrase1 algorithm list named<br>
phrase1_algs including like 3des-192-cbc-sha1, aes-128-cbc-sha1 etc. So as<br>
to support multiple algorithm proposals in one IKE negotiation. This could<br>
be considered in next release.<br>
<br>
2. Table IPSecPolicy<br>
a. encryption_algorithm, the same as IKEPolicy b. transform_protocol,<br>
encapsulation_mode. Suggest to remove them to make object and<br>
configuration simpler. We can focus on ESP and tunnel mode only for IPSec.<br>
This is typical site-to-site mode for Cloud user scenario. AH and<br>
transform mode are rarely used. The alternative solution is allowed that<br>
user can configure IPSecPolicy without specifying them(DB will store them<br>
as default value).<br>
c. pfs, the same as IKEPolicy<br>
d. A minor adjustment suggestion for encryption_algorithm and<br>
auth_algorithm, we can combine them into a phrase2 algorithm list named<br>
phrase2_algs like 3des-192-cbc-sha1, aes-128-cbc-sha1. So as to support<br>
multiple algorithm proposals in one IKE negotiation. This could be<br>
considered in next release.<br>
<br>
3. local_cidrs<br>
If we remove local_cidrs, where can we get local subnets parameter, from<br>
subnet id? Does "subnet_id" contain all the private subnets need to be<br>
protected over VPN tunnel? How to support two local private subnets over<br>
the same VPN tunnel(connection)?<br>
<br>
Thanks<br>
Qin<br>
<br>
-----Original Message-----<br>
From: Nachi Ueno [mailto:<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>]<br>
Sent: 2013年5月17日 7:10<br>
Cc: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] VPNaaS<br>
<br>
Hi folks<br>
<br>
We have meeting today.<br>
<br>
On IRC #openstack-meetings (It looks like free)<br>
<br>
Agenda :<br>
<br>
1.Driver archtecture<br>
<a href="https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHI
w_G1Dy5aQ/edit" target="_blank">https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHI<br>
w_G1Dy5aQ/edit</a><br>
[Conclution] keep reviewing<br>
Renamed driver name<br>
<br>
2. Agent archtecutre<br>
<a href="https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZ
Xq7SnSSGo/edit" target="_blank">https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZ<br>
Xq7SnSSGo/edit</a><br>
<br>
[Conclution]<br>
At first, take Option1 (implement it as sub-class of l3-agent)<br>
VPN-agent will be subclass of subclass of the l3 agent<br>
<br>
3.local_subnet vs local_cidr<br>
<br>
remove local_cidr until BGP is implemented and keep discussion<br>
keep peer_cidr<br>
keep discussions on mailing list<br>
<br>
4. Next meeting is not scheudled.<br>
We are continue discussion on gerrit.<br>
<br>
Munites.<br>
<a href="http://eavesdrop.openstack.org/meetings/openstack_networking__vpn_/2013/op
enstack_networking__vpn_.2013-05-16-22.03.html" target="_blank">http://eavesdrop.openstack.org/meetings/openstack_networking__vpn_/2013/op<br>
enstack_networking__vpn_.2013-05-16-22.03.html</a><br>
<br>
2013/5/15 Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>>:<br>
> Hi Llya<br>
><br>
> Wow. Sounds Great!<br>
> Thank you for your contribution.<br>
><br>
> Best<br>
> Nachi<br>
><br>
><br>
><br>
> 2013/5/15 Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>:<br>
>> Hi Nachi,<br>
>><br>
>> Tatyana and me volunteer for work on UI for VPNaaS. The corresponding<br>
>> bp is <a href="https://blueprints.launchpad.net/horizon/+spec/vpnaas-ui" target="_blank">https://blueprints.launchpad.net/horizon/+spec/vpnaas-ui</a>. We<br>
>> will start filling the specification soon.<br>
>><br>
>> Thanks,<br>
>> Ilya<br>
>><br>
>><br>
>> 2013/5/15 Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
>>><br>
>>> Hi Folks<br>
>>><br>
>>> We had VPN meetings yesterday.<br>
>>><br>
>>> Agenda :<br>
>>> 1. local_subnet vs local_cidr --> Keep discussion 2. Use cidr<br>
>>> value or subnet_id? --> Keep discussion 3. Task assignment<br>
>>> - move doc to wiki (Swami) Done<br>
>>> <a href="https://wiki.openstack.org/wiki/Quantum/VPNaaS" target="_blank">https://wiki.openstack.org/wiki/Quantum/VPNaaS</a><br>
>>> - Register BP and get approval by Mark (Swami) Done -> H2<br>
>>> - check default value for lifetime value (Swami) Done<br>
>>> - Implement Data Model (Swami will push code to the gerrit) by 5/20<br>
>>> - CLI (python-quantum client) work (Swami will push code to the<br>
>>> gerrit) by 5/20<br>
>>> - Implement Driver (Nachi & PCM ) by 5/31<br>
>>> - Investigate strongswan<br>
>>> - rpc (spec needed)<br>
>>> - Design driver archtecutre (spec needed)<br>
>>> - Write driver code<br>
>>> - Instation instructions on Wiki 5/31<br>
>>> - Devstack support (nati) late June?<br>
>>> - Write openstack network api document wiki (Sachin)<br>
>>> - Horizon work (needs contributer)<br>
>>> - Tempest (needs contributer)<br>
>>><br>
>>> Next meeting is 5/16 Thursday at 3pm (PST) . On IRC<br>
>>> #openstack-meetings<br>
>>><br>
>>> Meeting ended Tue May 14 01:00:58 2013 UTC. Information about<br>
>>> MeetBot at <a href="http://wiki.debian.org/MeetBot" target="_blank">http://wiki.debian.org/MeetBot</a> . (v 0.1.4)<br>
>>> Minutes:<br>
>>><br>
>>> <a href="http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201" target="_blank">http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201</a><br>
>>> 3/openstack_networking_vpn.2013-05-14-00.06.html<br>
>>> Minutes (text):<br>
>>><br>
>>> <a href="http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201" target="_blank">http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201</a><br>
>>> 3/openstack_networking_vpn.2013-05-14-00.06.txt<br>
>>> Log:<br>
>>><br>
>>> <a href="http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201" target="_blank">http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201</a><br>
>>> 3/openstack_networking_vpn.2013-05-14-00.06.log.htm<br>
>>><br>
>>> Thanks!<br>
>>> Nachi Ueno<br>
>>><br>
>>> 2013/5/10 Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>>:<br>
>>> > Hi Paul<br>
>>> ><br>
>>> > Thanks for your contributions! :)<br>
>>> ><br>
>>> > Nachi<br>
>>> ><br>
>>> > 2013/5/10 Paul Michali <<a href="mailto:pcm@cisco.com">pcm@cisco.com</a>>:<br>
>>> >> Sure! Glad to work with you Nachi. Anything I can do to help out<br>
>>> >> on the project!<br>
>>> >><br>
>>> >> I'll start looking at strongswan and how to configure.<br>
>>> >><br>
>>> >><br>
>>> >> Regards,<br>
>>> >><br>
>>> >> PCM (Paul Michali)<br>
>>> >><br>
>>> >><br>
>>> >> On May 10, 2013, at 12:35 PM, Nachi Ueno wrote:<br>
>>> >><br>
>>> >> Hi Paul<br>
>>> >><br>
>>> >> Sounds Great.<br>
>>> >><br>
>>> >> The first driver will be strong-swan based.<br>
>>> >> <a href="http://www.strongswan.org/" target="_blank">http://www.strongswan.org/</a><br>
>>> >><br>
>>> >> How about work with me to implement strong-swan vpn driver?<br>
>>> >> Honestly, i'm new to strong-swan, so I'm very appreciate if you<br>
>>> >> could try strong-swan on ubuntu and share how to configure it<br>
>>> >> based on current API model.<br>
>>> >><br>
>>> >> Thanks<br>
>>> >> Nachi<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2013/5/10 Paul Michali <<a href="mailto:pcm@cisco.com">pcm@cisco.com</a>>:<br>
>>> >><br>
>>> >> Naci, Mark, Swami, Sachin, et al,<br>
>>> >><br>
>>> >><br>
>>> >> Any suggestions on where/how I can help on this? I'm new to OS<br>
>>> >> (just working<br>
>>> >><br>
>>> >> it for a few months), so no specific expertise area, but have<br>
>>> >> bandwidth to<br>
>>> >><br>
>>> >> contribute.<br>
>>> >><br>
>>> >><br>
>>> >> Also, any pointers to information that will help me get up to<br>
>>> >> speed on this<br>
>>> >><br>
>>> >> would be appreciated (Mark gave me link to Amazon URL for info on<br>
>>> >> what they<br>
>>> >><br>
>>> >> provide for VPNaaS). I was going to look at LBaaS code next week<br>
>>> >> and have<br>
>>> >><br>
>>> >> been monitoring those discussions, as there seem to be some<br>
>>> >> parallels there.<br>
>>> >><br>
>>> >> If there are companion info that you think would help, let me know.<br>
>>> >><br>
>>> >><br>
>>> >> Regards,<br>
>>> >><br>
>>> >><br>
>>> >> PCM (Paul Michali)<br>
>>> >><br>
>>> >><br>
>>> >> On May 9, 2013, at 9:12 PM, Nachi Ueno wrote:<br>
>>> >><br>
>>> >><br>
>>> >> Hi Folks<br>
>>> >><br>
>>> >><br>
>>> >> We have meeting about VPN today.<br>
>>> >><br>
>>> >><br>
>>> >> #Conclusions<br>
>>> >><br>
>>> >> 1. We agreed ipsec api<br>
>>> >><br>
>>> >> <a href="https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis" target="_blank">https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis</a><br>
>>> >><br>
>>> >> 2. Swami will push api CRUD code to review (continue discussion<br>
>>> >> on<br>
>>> >> code)<br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis" target="_blank">https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis</a><br>
>>> >><br>
>>> >> 3. We agreed first implementation vpn architecture<br>
>>> >><br>
>>> >> 4. Next meeting is 5/13 PST 5:00 PM on #openstack-meetings<br>
>>> >><br>
>>> >><br>
>>> >> #Questions for IPSec API<br>
>>> >><br>
>>> >> 1 psk_key -> psk (agreed)<br>
>>> >><br>
>>> >> 2 For ipsecpolicy table, suggest to split lifetime into two parts<br>
>>> >><br>
>>> >> lifetime_s(per seconds) and lifetime_b(per kilobytes) -> updated<br>
>>> >><br>
>>> >> table (agreed)<br>
>>> >><br>
>>> >> 3 change back "cidrs" from subnet (or network) -> check marks's<br>
>>> >> thought<br>
>>> >><br>
>>> >> 4 For APIs, can we shorten the naming such as change -> keep<br>
>>> >> current<br>
>>> >><br>
>>> >> longer style for reability<br>
>>> >><br>
>>> >><br>
>>> >> #Project Management (Task)<br>
>>> >><br>
>>> >> - move doc to wiki (Swami)<br>
>>> >><br>
>>> >> - Register BP and get approval by Mark (Swami)<br>
>>> >><br>
>>> >> - check default value for lifetime value (Swami)<br>
>>> >><br>
>>> >> - Discuss Archtecture<br>
>>> >><br>
>>> >> - Implement Data Model (Swami will push code to the gerrit)<br>
>>> >><br>
>>> >> - Driver (Nachi?)<br>
>>> >><br>
>>> >> - CLI (python-quantum client) work (Swami will push code to the<br>
>>> >> gerrit)<br>
>>> >><br>
>>> >> - Write openstack network api document wiki (Sachin)<br>
>>> >><br>
>>> >> - Devstack support<br>
>>> >><br>
>>> >> - Horizon work<br>
>>> >><br>
>>> >> - Tempest<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://docs.google.com/a/ntti3.com/presentation/d/1J7k1eI13-3pQV" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1J7k1eI13-3pQV</a><br>
>>> >> wp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.p<br>
>>> >><br>
>>> >> Nachi<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2013/5/7 Qin Li <<a href="mailto:qili@vmware.com">qili@vmware.com</a>>:<br>
>>> >><br>
>>> >><br>
>>> >> Hi Swami,<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Thanks for your comments. All look good to me except local_cidrs,<br>
>>> >><br>
>>> >><br>
>>> >> peer_cidrs. "cidrs" may be clear for value type and validation,<br>
>>> >> but it is<br>
>>> >><br>
>>> >><br>
>>> >> unfamiliar for the existing VPN administrators. I think we might<br>
>>> >> use<br>
>>> >><br>
>>> >><br>
>>> >> subnets or networks to avoid introducing a new concept for users.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Regards<br>
>>> >><br>
>>> >><br>
>>> >> QinLi<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> -----Original Message-----<br>
>>> >><br>
>>> >><br>
>>> >> From: Vasudevan, Swaminathan (PNB Roseville)<br>
>>> >><br>
>>> >><br>
>>> >> [mailto:<a href="mailto:swaminathan.vasudevan@hp.com">swaminathan.vasudevan@hp.com</a>]<br>
>>> >><br>
>>> >><br>
>>> >> Sent: 2013年5月8日 1:25<br>
>>> >><br>
>>> >><br>
>>> >> To: OpenStack Development Mailing List<br>
>>> >><br>
>>> >><br>
>>> >> Subject: Re: [openstack-dev] VPNaaS<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Hi Qin Li,<br>
>>> >><br>
>>> >><br>
>>> >> See my answers inline.<br>
>>> >><br>
>>> >><br>
>>> >> Thanks.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> -----Original Message-----<br>
>>> >><br>
>>> >><br>
>>> >> From: Qin Li [mailto:<a href="mailto:qili@vmware.com">qili@vmware.com</a>]<br>
>>> >><br>
>>> >><br>
>>> >> Sent: Monday, May 06, 2013 8:37 PM<br>
>>> >><br>
>>> >><br>
>>> >> To: OpenStack Development Mailing List<br>
>>> >><br>
>>> >><br>
>>> >> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> I'd like to share some of my comments on data models, tables,<br>
>>> >> APIs defined<br>
>>> >><br>
>>> >><br>
>>> >> in link<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ" target="_blank">https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ</a><br>
>>> >> Q1_PYkEx5<br>
>>> >><br>
>>> >><br>
>>> >> J4aO5J5Q74R_PwgV8/edit .<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 1. For VPNServiceConnection table<br>
>>> >><br>
>>> >><br>
>>> >> a. suggest to remove psk(Boolean) key defined in<br>
>>> >> VPNServiceConnection<br>
>>> >><br>
>>> >><br>
>>> >> table. There is already key auth_mode defined in ikepolicy table.<br>
>>> >><br>
>>> >><br>
>>> >> "auth_mode" can be "psk" or "certificate". By default, if not<br>
>>> >> set, it is<br>
>>> >><br>
>>> >><br>
>>> >> psk mode for authentication. Still keeping psk_key inside<br>
>>> >><br>
>>> >><br>
>>> >> VPNServiceConnection since psk_key is different per remote peer.<br>
>>> >><br>
>>> >><br>
>>> >> Authentication mode is a part of IKE property.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - Yes we had both the auth_mode and psk_key as part of the<br>
>>> >> IKEPolicy<br>
>>> >><br>
>>> >><br>
>>> >> table. We moved both the fields to the connection table since,<br>
>>> >> we just<br>
>>> >><br>
>>> >><br>
>>> >> wanted to re-use the IKEPolicy for different connections if only<br>
>>> >> the PSK<br>
>>> >><br>
>>> >><br>
>>> >> key changes or the auth_mode changes. Also in the document we<br>
>>> >> make<br>
>>> >><br>
>>> >><br>
>>> >> necessary changes to the table definition, but I need to make the<br>
>>> >> change<br>
>>> >><br>
>>> >><br>
>>> >> also in the datamodel table.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> b. suggest to change local_cidrs and peer_cidrs to<br>
>>> >> local_networks(or<br>
>>> >><br>
>>> >><br>
>>> >> local_subnets) and peer_networks(per_subnets) in<br>
>>> >> VPNServiceConnection<br>
>>> >><br>
>>> >><br>
>>> >> table. Cidrs is not a familiar keyword to users in IPSec<br>
industry.<br>
>>> >> Some<br>
>>> >><br>
>>> >><br>
>>> >> IPSec VPN vendors use subnets, some use networks.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - Yes we had initially defined it as peer_subnets and<br>
>>> >> local_subnets,<br>
>>> >><br>
>>> >><br>
>>> >> but based on yesterday's discussion we moved it to "cidrs", since<br>
>>> >> it would<br>
>>> >><br>
>>> >><br>
>>> >> be clear.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> c. suggest to change psk_key to psk, psk already means pre-shared<br>
key.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - Accepted we will change this.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2. For ipsecpolicy table, suggest to split lifetime into two<br>
>>> >> parts<br>
>>> >><br>
>>> >><br>
>>> >> lifetime_s(per seconds) and lifetime_b(per kilobytes).<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - Yes we can discuss about this in Thursday's meeting.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 3. Can we shorten the naming of keywords? Such as change<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - We can discuss about this in Thursday's meeting. The<br>
>>> >> reason we<br>
>>> >><br>
>>> >><br>
>>> >> don't want to have abbreviated keys is for people to understand<br>
>>> >> the keys<br>
>>> >><br>
>>> >><br>
>>> >> properly.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> In vpnserviceconnections table<br>
>>> >><br>
>>> >><br>
>>> >> vpnservice_ipsecpolicy_id to ipsecpolicy_id<br>
>>> >><br>
>>> >><br>
>>> >> vpnservice_ikepolicy_id to ikepolicy_id<br>
>>> >><br>
>>> >><br>
>>> >> vpnservice_certificiate_id to certificate_id<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> In ikepolicys table<br>
>>> >><br>
>>> >><br>
>>> >> auth_algorithm to auth_alg<br>
>>> >><br>
>>> >><br>
>>> >> encryption_algorithm to enc_alg<br>
>>> >><br>
>>> >><br>
>>> >> phraseI_negotiation_mode to phraseI_mode<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> In ipsecpolicys table<br>
>>> >><br>
>>> >><br>
>>> >> transform_protocol to protocol<br>
>>> >><br>
>>> >><br>
>>> >> auth_algorithm to auth_alg<br>
>>> >><br>
>>> >><br>
>>> >> encryption_algorithm to enc_alg<br>
>>> >><br>
>>> >><br>
>>> >> encapsulation_mode to mode or encap_mode<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 4. There might be some updates to set proper length for each<br>
>>> >> value in the<br>
>>> >><br>
>>> >><br>
>>> >> tables. Such as change<br>
>>> >><br>
>>> >><br>
>>> >> auth_algorithm VARCHAR2(255) to auth_alg VARCHAR2(8) ;<br>
for<br>
>>> >><br>
>>> >><br>
>>> >> example "sha1" etc.<br>
>>> >><br>
>>> >><br>
>>> >> encryption_algorithm VARCHAR2(255) to enc_alg VARCHAR2(16) ;<br>
for<br>
>>> >><br>
>>> >><br>
>>> >> example "aes128-cbc", "aes256-cbc" etc.<br>
>>> >><br>
>>> >><br>
>>> >> name VARCHAR2(255) to name VARCHAR2(64)<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - Yes we will make the necessary changes in the table.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 5. What do "dh" and "tls" keywords mean in table<br>
vpnservicecertficates?<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami - This was mainly included in the certificate table to<br>
>>> >> address the<br>
>>> >><br>
>>> >><br>
>>> >> "Openvpn" certificate requirements. This will be dropped for now.<br>
>>> >> Also we<br>
>>> >><br>
>>> >><br>
>>> >> are not considering to implement the certificates for this<br>
>>> >> release. We<br>
>>> >><br>
>>> >><br>
>>> >> will clean up the tables.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 6. For APIs, can we shorten the naming such as change<br>
>>> >><br>
>>> >><br>
>>> >> /v1.0/vpnservicecertificates/vpnservice_certificate_id to<br>
>>> >><br>
>>> >><br>
>>> >> /v1.0/vpncerts/certificate_id<br>
>>> >><br>
>>> >><br>
>>> >> /v1.0/vpnserviceconnections/vpnservice_conn_id to<br>
>>> >><br>
>>> >><br>
>>> >> /v1.0/vpnsrvconns/conn_id<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Swami: We can discuss in Thursday's meeting.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Thanks & Regards<br>
>>> >><br>
>>> >><br>
>>> >> Qin<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> -----Original Message-----<br>
>>> >><br>
>>> >><br>
>>> >> From: Nachi Ueno [mailto:<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>]<br>
>>> >><br>
>>> >><br>
>>> >> Sent: 2013年5月7日 9:07<br>
>>> >><br>
>>> >><br>
>>> >> To: OpenStack Development Mailing List<br>
>>> >><br>
>>> >><br>
>>> >> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Hi folks<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> In today's meeting, we are almost finished to define data models.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ" target="_blank">https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ</a><br>
>>> >> Q1_PYkEx5<br>
>>> >><br>
>>> >><br>
>>> >> J4aO5J5Q74R_PwgV8/edit<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> If you have any concerns, please commet it on the doc or question<br>
>>> >> on the<br>
>>> >><br>
>>> >><br>
>>> >> mailing list.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> We will have meeting at<br>
>>> >><br>
>>> >><br>
>>> >> 5/9 (Thu) 5:00 (PST)<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> In the next meeting, we will discuss more project management<br>
>>> >> oriented<br>
>>> >><br>
>>> >><br>
>>> >> discussion.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Thanks<br>
>>> >><br>
>>> >><br>
>>> >> Nachi<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2013/5/6 Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>>:<br>
>>> >><br>
>>> >><br>
>>> >> Hi folks<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Here is note from the meeting at 2nd meeting on VPN # sorry I<br>
>>> >> thought<br>
>>> >><br>
>>> >><br>
>>> >> I have sent it to the mailing list, but it looks not delivery.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 1) FirstStep SSL-VPN or IPSec? -> IPSec<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> - all atenndes agrees with IPSec first step<br>
>>> >><br>
>>> >><br>
>>> >> - IPSec is widely used so, this is big win to the community<br>
>>> >><br>
>>> >><br>
>>> >> - IPSec can support remote user use case<br>
>>> >><br>
>>> >><br>
>>> >> - SSL-VPN (CloudPipe) can be supported by OpenVPN VM with<br>
>>> >> floating ips<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2) GenricService API -> Agreed<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> -id<br>
>>> >><br>
>>> >><br>
>>> >> -name<br>
>>> >><br>
>>> >><br>
>>> >> -tenant_id<br>
>>> >><br>
>>> >><br>
>>> >> -type (VPN type)<br>
>>> >><br>
>>> >><br>
>>> >> type has namespace (should be flat)<br>
>>> >><br>
>>> >><br>
>>> >> l2 vpn -> l2.*** (l2.l2tp)<br>
>>> >><br>
>>> >><br>
>>> >> l3 vpn -> l3.** (l3.ipsec)<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 3) IPSec API set<br>
>>> >><br>
>>> >><br>
>>> >> Start discussion for IPSec api on the google doc<br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ" target="_blank">https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ</a><br>
>>> >> Q1_PY<br>
>>> >><br>
>>> >><br>
>>> >> kEx5J4aO5J5Q74R_PwgV8/edit<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 4) Next meeting time<br>
>>> >><br>
>>> >><br>
>>> >> PST Monday 5PM (Sactin@VMWare will reserve conf-call)<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Meeting Agenda and Note<br>
>>> >><br>
>>> >><br>
>>> >> <a href="https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzU" target="_blank">https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzU</a><br>
>>> >> vuSqc<br>
>>> >><br>
>>> >><br>
>>> >> zRdK0lEZKQOKk/edit#slide=id.p<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Thanks!<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> 2013/5/1 Sachin Thakkar <<a href="mailto:sthakkar@vmware.com">sthakkar@vmware.com</a>>:<br>
>>> >><br>
>>> >><br>
>>> >> Thanks folks for joining today. We've made some good progress on<br>
>>> >> the<br>
>>> >><br>
>>> >><br>
>>> >> IPsec VPN object model. Nachi has sent out the meeting notes to<br>
>>> >> the<br>
>>> >><br>
>>> >><br>
>>> >> alias as well.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> We'll need another follow up to continue the discussion. The<br>
>>> >> meeting<br>
>>> >><br>
>>> >><br>
>>> >> will be at 5pm Pacific time on Monday, May 6.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> The same bridge below will be used.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Thanks,<br>
>>> >><br>
>>> >><br>
>>> >> Sachin<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> ________________________________<br>
>>> >><br>
>>> >><br>
>>> >> From: "Sachin Thakkar" <<a href="mailto:sthakkar@vmware.com">sthakkar@vmware.com</a>><br>
>>> >><br>
>>> >><br>
>>> >> To: "OpenStack Development Mailing List<br>
(openstack-dev@lists.openstack.<br>
>>> >><br>
>>> >><br>
>>> >> org)"<br>
>>> >><br>
>>> >><br>
>>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>> >><br>
>>> >><br>
>>> >> Sent: Thursday, April 25, 2013 11:43:30 PM<br>
>>> >><br>
>>> >><br>
>>> >> Subject: [openstack-dev] [Quantum] [Networking] VPNaaS<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Trying the new Networking tag in the subject :)<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Anyway, we have a kickoff call for VPNaaS scheduled next<br>
>>> >> Wednesday @<br>
>>> >><br>
>>> >><br>
>>> >> 5pm Pacific time. We will be discussing over the phone:<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Participant Passcode: 697 737 3510<br>
>>> >><br>
>>> >><br>
>>> >> Call-in toll-free number (Premiere): 1-866-715-6501 (US)<br>
>>> >> Additional<br>
>>> >><br>
>>> >><br>
>>> >> International Numbers:<br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c2558" target="_blank">http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c2558</a><br>
>>> >> 5184<br>
>>> >><br>
>>> >><br>
>>> >> f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298<br>
>>> >> f8a5<br>
>>> >><br>
>>> >><br>
>>> >> 9d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151<br>
>>> >> c4b3<br>
>>> >><br>
>>> >><br>
>>> >> 0a31fa1b2<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> To all interested, hope to see you there.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> Cheers,<br>
>>> >><br>
>>> >><br>
>>> >> Sachin<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >><br>
>>> >> OpenStack-dev mailing list<br>
>>> >><br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >> OpenStack-dev mailing list<br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> _______________________________________________<br>
>>> >> OpenStack-dev mailing list<br>
>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> >><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>