[openstack-dev] VPNaaS
Nachi Ueno
nachi at ntti3.com
Fri May 10 16:35:30 UTC 2013
Hi Paul
Sounds Great.
The first driver will be strong-swan based.
http://www.strongswan.org/
How about work with me to implement strong-swan vpn driver?
Honestly, i'm new to strong-swan, so I'm very appreciate if you
could try strong-swan on ubuntu and share how to configure it based on
current API model.
Thanks
Nachi
2013/5/10 Paul Michali <pcm at cisco.com>:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list