[openstack-dev] VPNaaS
Qin Li
qili at vmware.com
Wed May 8 02:17:52 UTC 2013
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
More information about the OpenStack-dev
mailing list