[openstack-dev] VPNaaS

Nachi Ueno nachi at ntti3.com
Fri May 10 01:12:40 UTC 2013


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



More information about the OpenStack-dev mailing list