[openstack-dev] VPNaaS

Paul Michali pcm at cisco.com
Fri May 10 10:27:09 UTC 2013


Naci, Mark, Swami, Sachin, et al,

Any suggestions on where/how I can help on this? I'm new to OS (just working it for a few months), so no specific expertise area, but have bandwidth to contribute.

Also, any pointers to information that will help me get up to speed on this would be appreciated (Mark gave me link to Amazon URL for info on what they provide for VPNaaS). I was going to look at LBaaS code next week and have been monitoring those discussions, as there seem to be some parallels there. If there are companion info that you think would help, let me know.

Regards,

PCM (Paul Michali)

On May 9, 2013, at 9:12 PM, Nachi Ueno wrote:

> Hi Folks
> 
> We have meeting about VPN today.
> 
> #Conclusions
> 1. We agreed ipsec api
> https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis
> 2. Swami will push api CRUD code to review (continue discussion on code)
>   https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis
> 3. We agreed first implementation vpn architecture
> 4. Next meeting is 5/13 PST 5:00 PM on #openstack-meetings
> 
> #Questions for IPSec API
> 1 psk_key -> psk (agreed)
> 2 For ipsecpolicy table, suggest to split lifetime into two parts
> lifetime_s(per seconds) and lifetime_b(per kilobytes)   ->  updated
> table (agreed)
> 3 change back "cidrs" from subnet (or network)  -> check marks's thought
> 4 For APIs, can we shorten the naming such as change  -> keep current
> longer style for reability
> 
> #Project Management (Task)
>  -  move doc to wiki (Swami)
>  -  Register BP and get approval by Mark (Swami)
>  -  check default value for lifetime value (Swami)
>  -  Discuss Archtecture
>  -  Implement Data Model (Swami will push code to the gerrit)
>  -  Driver (Nachi?)
>  -  CLI (python-quantum client) work (Swami will push code to the gerrit)
>  -  Write openstack network api document wiki (Sachin)
>  -  Devstack support
>  -  Horizon work
>  -  Tempest
> 
> https://docs.google.com/a/ntti3.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.p
> Nachi
> 
> 
> 2013/5/7 Qin Li <qili at vmware.com>:
>> Hi Swami,
>> 
>> Thanks for your comments. All look good to me except local_cidrs,
>> peer_cidrs. "cidrs" may be clear for value type and validation, but it is
>> unfamiliar for the existing VPN administrators. I think we might use
>> subnets or networks to avoid introducing a new concept for users.
>> 
>> Regards
>> QinLi
>> 
>> -----Original Message-----
>> From: Vasudevan, Swaminathan (PNB Roseville)
>> [mailto:swaminathan.vasudevan at hp.com]
>> Sent: 2013年5月8日 1:25
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] VPNaaS
>> 
>> Hi Qin Li,
>> See my answers inline.
>> Thanks.
>> 
>> -----Original Message-----
>> From: Qin Li [mailto:qili at vmware.com]
>> Sent: Monday, May 06, 2013 8:37 PM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS
>> 
>> I'd like to share some of my comments on data models, tables, APIs defined
>> in link
>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZQ1_PYkEx5
>> J4aO5J5Q74R_PwgV8/edit .
>> 
>> 1. For VPNServiceConnection table
>> a. suggest to remove psk(Boolean) key defined in VPNServiceConnection
>> table. There is already key auth_mode defined in ikepolicy table.
>> "auth_mode" can be "psk" or "certificate". By default, if not set, it is
>> psk mode for authentication. Still keeping psk_key inside
>> VPNServiceConnection since psk_key is different per remote peer.
>> Authentication mode is a part of IKE property.
>> 
>> Swami - Yes we had both the auth_mode and psk_key as part of the IKEPolicy
>> table.  We moved both the fields to the connection table since, we just
>> wanted to re-use the IKEPolicy for different connections if only the PSK
>> key changes or the auth_mode changes. Also in the document we make
>> necessary changes to the table definition, but I need to make the change
>> also in the datamodel table.
>> 
>> 
>> b. suggest to change local_cidrs and peer_cidrs to local_networks(or
>> local_subnets) and peer_networks(per_subnets) in VPNServiceConnection
>> table.   Cidrs is not a familiar keyword to users in IPSec industry. Some
>> IPSec VPN vendors use subnets, some use networks.
>> 
>> Swami - Yes we had initially defined it as peer_subnets and local_subnets,
>> but based on yesterday's discussion we moved it to "cidrs", since it would
>> be clear.
>> 
>> c. suggest to change psk_key to psk,  psk already means pre-shared key.
>> 
>> Swami - Accepted we will change this.
>> 
>> 2. For ipsecpolicy table, suggest to split lifetime into two parts
>> lifetime_s(per seconds) and lifetime_b(per kilobytes).
>> 
>> Swami - Yes we can discuss about this in Thursday's meeting.
>> 
>> 3. Can we shorten the naming of keywords? Such as change
>> 
>> Swami - We can discuss about this in Thursday's meeting. The reason we
>> don't want to have abbreviated keys is for people to understand the keys
>> properly.
>> 
>> 
>>   In vpnserviceconnections table
>>   vpnservice_ipsecpolicy_id  to  ipsecpolicy_id
>>   vpnservice_ikepolicy_id    to  ikepolicy_id
>>   vpnservice_certificiate_id to  certificate_id
>> 
>> 
>>   In ikepolicys table
>>   auth_algorithm           to auth_alg
>>   encryption_algorithm     to enc_alg
>>   phraseI_negotiation_mode to phraseI_mode
>> 
>>   In ipsecpolicys table
>>   transform_protocol       to protocol
>>   auth_algorithm           to auth_alg
>>   encryption_algorithm     to enc_alg
>>   encapsulation_mode       to mode or encap_mode
>> 
>> 4. There might be some updates to set proper length for each value in the
>> tables. Such as change
>>   auth_algorithm VARCHAR2(255)       to auth_alg  VARCHAR2(8)   ; for
>> example "sha1" etc.
>>   encryption_algorithm VARCHAR2(255) to enc_alg   VARCHAR2(16)   ; for
>> example "aes128-cbc", "aes256-cbc" etc.
>>   name VARCHAR2(255)                 to name      VARCHAR2(64)
>> 
>> Swami - Yes we will make the necessary changes in the table.
>> 
>> 5. What do "dh" and "tls" keywords mean in table vpnservicecertficates?
>> 
>> Swami - This was mainly included in the certificate table to address the
>> "Openvpn" certificate requirements. This will be dropped for now. Also we
>> are not considering to implement the certificates for this release. We
>> will clean up the tables.
>> 
>> 6. For APIs, can we shorten the naming such as change
>>   /v1.0/vpnservicecertificates/vpnservice_certificate_id  to
>> /v1.0/vpncerts/certificate_id
>>   /v1.0/vpnserviceconnections/vpnservice_conn_id          to
>> /v1.0/vpnsrvconns/conn_id
>> 
>> Swami: We can discuss in Thursday's meeting.
>> 
>> Thanks & Regards
>> Qin
>> 
>> 
>> -----Original Message-----
>> From: Nachi Ueno [mailto:nachi at ntti3.com]
>> Sent: 2013年5月7日 9:07
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS
>> 
>> Hi folks
>> 
>> In today's meeting, we are almost finished to define data models.
>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZQ1_PYkEx5
>> J4aO5J5Q74R_PwgV8/edit
>> 
>> If you have any concerns, please commet it on the doc or question on the
>> mailing list.
>> 
>> We will have meeting at
>> 5/9 (Thu) 5:00 (PST)
>> 
>> In the next meeting, we will discuss more project management oriented
>> discussion.
>> 
>> Thanks
>> Nachi
>> 
>> 2013/5/6 Nachi Ueno <nachi at ntti3.com>:
>>> Hi folks
>>> 
>>> Here is note from the meeting at 2nd meeting on VPN # sorry I thought
>>> I have sent it to the mailing list, but it looks not delivery.
>>> 
>>> 1) FirstStep  SSL-VPN or IPSec?  -> IPSec
>>> 
>>> - all atenndes agrees with IPSec first step
>>> - IPSec is widely used so, this is big win to the community
>>> - IPSec can support remote user use case
>>> - SSL-VPN (CloudPipe) can be supported by OpenVPN VM with floating ips
>>> 
>>> 2) GenricService API -> Agreed
>>> 
>>> -id
>>> -name
>>> -tenant_id
>>> -type (VPN type)
>>> type has namespace (should be flat)
>>> l2 vpn -> l2.*** (l2.l2tp)
>>> l3 vpn -> l3.** (l3.ipsec)
>>> 
>>> 3) IPSec API set
>>> Start discussion for IPSec api on the google doc
>>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZQ1_PY
>>> kEx5J4aO5J5Q74R_PwgV8/edit
>>> 
>>> 4) Next meeting time
>>> PST Monday 5PM (Sactin at VMWare will reserve conf-call)
>>> 
>>> Meeting Agenda and Note
>>> https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzUvuSqc
>>> zRdK0lEZKQOKk/edit#slide=id.p
>>> 
>>> Thanks!
>>> 
>>> 2013/5/1 Sachin Thakkar <sthakkar at vmware.com>:
>>>> Thanks folks for joining today. We've made some good progress on the
>>>> IPsec VPN object model. Nachi has sent out the meeting notes to the
>> alias as well.
>>>> 
>>>> We'll need another follow up to continue the discussion. The meeting
>>>> will be at 5pm Pacific time on Monday, May 6.
>>>> 
>>>> The same bridge below will be used.
>>>> 
>>>> Thanks,
>>>> Sachin
>>>> 
>>>> ________________________________
>>>> From: "Sachin Thakkar" <sthakkar at vmware.com>
>>>> To: "OpenStack Development Mailing List (openstack-dev at lists.openstack.
>> org)"
>>>> <openstack-dev at lists.openstack.org>
>>>> Sent: Thursday, April 25, 2013 11:43:30 PM
>>>> Subject: [openstack-dev] [Quantum] [Networking] VPNaaS
>>>> 
>>>> 
>>>> Trying the new Networking tag in the subject :)
>>>> 
>>>> Anyway, we have a kickoff call for VPNaaS scheduled next Wednesday @
>>>> 5pm Pacific time. We will be discussing over the phone:
>>>> 
>>>> Participant Passcode: 697 737 3510
>>>> Call-in toll-free number (Premiere): 1-866-715-6501 (US) Additional
>>>> International Numbers:
>>>> http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c25585184
>>>> f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298f8a5
>>>> 9d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151c4b3
>>>> 0a31fa1b2
>>>> 
>>>> To all interested, hope to see you there.
>>>> 
>>>> Cheers,
>>>> Sachin
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/ecccbb56/attachment.html>


More information about the OpenStack-dev mailing list