[openstack-dev] VPNaaS
Nachi Ueno
nachi at ntti3.com
Tue May 21 20:40:54 UTC 2013
Hi Folks
> Francois
Thank you for your investigation!
I would like to got with openswan because for cmd line config support.
> Paul, Swami
Is this OK for you guys?
Nachi
2013/5/21 Eleouet Francois <f.eleouet at gmail.com>:
> In Openswan, both protocol versions are implemented in the same daemon, by
> default, both versions are enabled, IKEv2 parameter must be added to conn
> section to choose between versions:
>
> ikev2=never #will prevent responding to IKEv2
> ikev2=insist #will force the use of IKEv2
>
> 2013/5/20 Paul Michali <pcm at cisco.com>
>>
>> Very cool information Francois
>>
>> The example you have is with pluto. That's for IKEv1, right?
>>
>> Is there an equivalent for charon (IKEv2)?
>>
>> Regards,
>>
>>
>> PCM (Paul Michali)
>>
>> On May 20, 2013, at 7:22 AM, Eleouet Francois wrote:
>>
>> Yes, but It may take some time to land in distros...
>>
>> In the meantime, we could also consider using openswan that hasn't the
>> same caveats: it can be launched with router-specific conf, pid & control
>> socket files, as shown in the following sample:
>>
>> ip netns exec moon ipsec pluto --ctlbase /var/lib/quantum/ipsec/moon/pluto
>> --ipsecdir /var/lib/quantum/ipsec/moon/ --use-auto --uniqueids
>> --nat_traversal --secretsfile /var/lib/quantum/ipsec/moon/ipsec.secrets
>> ip netns exec moon ipsec addconn --ctlbase
>> /var/lib/quantum/ipsec/moon/pluto.ctl --config
>> /var/lib/quantum/ipsec/moon/ipsec.conf moon-sun
>> ip netns exec moon ipsec whack --ctlbase /var/lib/quantum/ipsec/moon/pluto
>> --listen
>>
>> ip netns exec sun ipsec pluto --ctlbase /var/lib/quantum/ipsec/sun/pluto
>> --ipsecdir /var/lib/quantum/ipsec/sun/ --use-auto --uniqueids
>> --nat_traversal --secretsfile /var/lib/quantum/ipsec/sun/ipsec.secrets
>> ip netns exec sun ipsec addconn --ctlbase
>> /var/lib/quantum/ipsec/sun/pluto.ctl --config
>> /var/lib/quantum/ipsec/sun/ipsec.conf sun-moon
>> ip netns exec sun ipsec whack --ctlbase /var/lib/quantum/ipsec/sun/pluto
>> --listen
>> ip netns exec sun ipsec whack --ctlbase /var/lib/quantum/ipsec/sun/pluto
>> --name sun-moon --initiate
>>
>> /var/lib/quantum/ipsec/moon/ipsec.conf:
>> config setup
>> nat_traversal=yes
>> protostack=auto
>>
>> conn moon-sun
>> authby=secret
>> left=192.168.1.1
>> leftsubnet=10.1.0.0/16
>> leftid=@moon.openstack.org
>> right=192.168.1.2
>> rightsubnet=10.2.0.0/16
>> rightid=@sun.openstack.org
>> auto=add
>>
>> /var/lib/quantum/ipsec/moon/ipsec.secrets:
>> @moon.openstack.org %any : PSK "very secret psk"
>>
>> (sun confs are symetrical)
>>
>>
>> 2013/5/20 Clark, Robert Graham <robert.clark at hp.com>
>>>
>>> Should be easy enough to change the ugly bit upstream.
>>>
>>> http://wiki.strongswan.org/projects/strongswan/wiki/Contributions
>>>
>>> From: Eleouet Francois <f.eleouet at gmail.com<mailto:f.eleouet at gmail.com>>
>>> Reply-To: OpenStack List
>>> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>>> Date: Friday, 17 May 2013 19:44
>>> To: OpenStack List
>>> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPNaaS
>>>
>>> Hi,
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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:
>>>
>>> #set up IPsec connection between two router namespaces on the same host:
>>>
>>> ip netns add moon
>>> ip netns add sun
>>> ip link add veth-sun type veth peer name veth-moon
>>> ip link set veth-sun netns sun
>>> ip link set veth-moon netns moon
>>>
>>> ip netns exec moon ip addr add 192.168.1.1/24<http://192.168.1.1/24> dev
>>> veth-moon
>>> ip netns exec moon ip addr add 10.1.0.1/8<http://10.1.0.1/8> dev
>>> veth-moon
>>> ip netns exec moon ip link set veth-moon up
>>> ip netns exec moon ip link set lo up
>>>
>>> ip netns exec sun ip addr add 192.168.1.2/24<http://192.168.1.2/24> dev
>>> veth-sun
>>> ip netns exec sun ip addr add 10.2.0.1/8<http://10.2.0.1/8> dev veth-sun
>>> ip netns exec sun ip link set veth-sun up
>>> ip netns exec sun ip link set lo up
>>>
>>> ip netns exec moon ipsec start
>>> ip netns exec moon ipsec up moon-sun &
>>>
>>> #here comes the uggly part:
>>> rm /var/run/charon.pid
>>> rm /var/run/pluto.pid
>>> rm /var/run/starter.pid
>>>
>>> ip netns exec sun ipsec start
>>> ip netns exec sun ipsec up sun-moon &
>>>
>>> The correponding ipsec.conf
>>>
>>> config setup
>>> charonstart=yes
>>> plutostart=yes
>>>
>>> conn %default
>>> ikelifetime=60m
>>> keylife=20m
>>> rekeymargin=3m
>>> keyingtries=1
>>> authby=secret
>>> keyexchange=ikev2
>>> mobike=no
>>>
>>> conn moon-sun
>>> left=192.168.1.1
>>> leftsubnet=10.1.0.0/16<http://10.1.0.0/16>
>>> leftid=@moon.strongswan.org<http://moon.strongswan.org/>
>>> leftfirewall=yes
>>> right=192.168.1.2
>>> rightsubnet=10.2.0.0/16<http://10.2.0.0/16>
>>> rightid=@sun.strongswan.org<http://sun.strongswan.org/>
>>> auto=add
>>>
>>> conn sun-moon
>>> left=192.168.1.2
>>> leftsubnet=10.2.0.0/16<http://10.2.0.0/16>
>>> leftid=@moon.strongswan.org<http://moon.strongswan.org/>
>>> leftfirewall=yes
>>> right=192.168.1.1
>>> rightsubnet=10.1.0.0/16<http://10.1.0.0/16>
>>> rightid=@sun.strongswan.org<http://sun.strongswan.org/>
>>> auto=add
>>>
>>> Any thoughts on that?
>>>
>>> Francois.
>>>
>>>
>>> 2013/5/17 Qin Li <qili at vmware.com<mailto:qili at vmware.com>>
>>> + one more comment for 3. Local_cidrs
>>> If there are there subnets got from "subnet_id" and user only wish to
>>> provide VPN tunnel access to two of them from remote, we need to keep
>>> local_cidrs.
>>>
>>> Thanks
>>> Qin
>>>
>>> -----Original Message-----
>>> From: Qin Li [mailto:qili at vmware.com<mailto:qili at vmware.com>]
>>> Sent: 2013年5月17日 9:55
>>> To: OpenStack Development Mailing List
>>> Subject: RE: [openstack-dev] VPNaaS
>>>
>>> For design on https://wiki.openstack.org/wiki/Quantum/VPNaaS , I'd like
>>> to
>>> share some of my comments.
>>>
>>> 1. Table IKEPolicy
>>> a. encryption_algorithm, please include more information about algorithm
>>> such as cipher mode. The value could be 3des-192-cbc, aes-128-cbc,
>>> aes-192-cbc, aes-256-cbc, aes-128-gcm-a, aes-256-gcm-a, aes-128-ccm etc.
>>> So as to support more kinds of cipher modes.
>>> b. phase1_negotiation_mode, suggest to rename it as phrase1_mode or mode,
>>> phrase 1 already contains the meaning "negotiation".
>>> c. pfs, since there is no pfs_enable flag, null value of pfs means
>>> disabled. What does it mean if user does not specify it in inputs?
>>> d. A minor adjustment suggestion for encryption_algorithm and
>>> auth_algorithm, we could combine them into a phrase1 algorithm list named
>>> phrase1_algs including like 3des-192-cbc-sha1, aes-128-cbc-sha1 etc. So
>>> as
>>> to support multiple algorithm proposals in one IKE negotiation. This
>>> could
>>> be considered in next release.
>>>
>>> 2. Table IPSecPolicy
>>> a. encryption_algorithm, the same as IKEPolicy b. transform_protocol,
>>> encapsulation_mode. Suggest to remove them to make object and
>>> configuration simpler. We can focus on ESP and tunnel mode only for
>>> IPSec.
>>> This is typical site-to-site mode for Cloud user scenario. AH and
>>> transform mode are rarely used. The alternative solution is allowed that
>>> user can configure IPSecPolicy without specifying them(DB will store them
>>> as default value).
>>> c. pfs, the same as IKEPolicy
>>> d. A minor adjustment suggestion for encryption_algorithm and
>>> auth_algorithm, we can combine them into a phrase2 algorithm list named
>>> phrase2_algs like 3des-192-cbc-sha1, aes-128-cbc-sha1. So as to support
>>> multiple algorithm proposals in one IKE negotiation. This could be
>>> considered in next release.
>>>
>>> 3. local_cidrs
>>> If we remove local_cidrs, where can we get local subnets parameter, from
>>> subnet id? Does "subnet_id" contain all the private subnets need to be
>>> protected over VPN tunnel? How to support two local private subnets over
>>> the same VPN tunnel(connection)?
>>>
>>> Thanks
>>> Qin
>>>
>>> -----Original Message-----
>>> From: Nachi Ueno [mailto:nachi at ntti3.com<mailto:nachi at ntti3.com>]
>>> Sent: 2013年5月17日 7:10
>>> Cc: OpenStack Development Mailing List
>>> Subject: Re: [openstack-dev] VPNaaS
>>>
>>> Hi folks
>>>
>>> We have meeting today.
>>>
>>> On IRC #openstack-meetings (It looks like free)
>>>
>>> Agenda :
>>>
>>> 1.Driver archtecture
>>>
>>> https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHI
>>> w_G1Dy5aQ/edit
>>> [Conclution] keep reviewing
>>> Renamed driver name
>>>
>>> 2. Agent archtecutre
>>>
>>> https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZ
>>> Xq7SnSSGo/edit
>>>
>>> [Conclution]
>>> At first, take Option1 (implement it as sub-class of l3-agent)
>>> VPN-agent will be subclass of subclass of the l3 agent
>>>
>>> 3.local_subnet vs local_cidr
>>>
>>> remove local_cidr until BGP is implemented and keep discussion
>>> keep peer_cidr
>>> keep discussions on mailing list
>>>
>>> 4. Next meeting is not scheudled.
>>> We are continue discussion on gerrit.
>>>
>>> Munites.
>>>
>>> http://eavesdrop.openstack.org/meetings/openstack_networking__vpn_/2013/op
>>> enstack_networking__vpn_.2013-05-16-22.03.html
>>>
>>> 2013/5/15 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>:
>>> > Hi Llya
>>> >
>>> > Wow. Sounds Great!
>>> > Thank you for your contribution.
>>> >
>>> > Best
>>> > Nachi
>>> >
>>> >
>>> >
>>> > 2013/5/15 Ilya Shakhat
>>> > <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>>:
>>> >> Hi Nachi,
>>> >>
>>> >> Tatyana and me volunteer for work on UI for VPNaaS. The corresponding
>>> >> bp is https://blueprints.launchpad.net/horizon/+spec/vpnaas-ui. We
>>> >> will start filling the specification soon.
>>> >>
>>> >> Thanks,
>>> >> Ilya
>>> >>
>>> >>
>>> >> 2013/5/15 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>
>>> >>>
>>> >>> Hi Folks
>>> >>>
>>> >>> We had VPN meetings yesterday.
>>> >>>
>>> >>> Agenda :
>>> >>> 1. local_subnet vs local_cidr --> Keep discussion 2. Use cidr
>>> >>> value or subnet_id? --> Keep discussion 3. Task assignment
>>> >>> - move doc to wiki (Swami) Done
>>> >>> https://wiki.openstack.org/wiki/Quantum/VPNaaS
>>> >>> - Register BP and get approval by Mark (Swami) Done -> H2
>>> >>> - check default value for lifetime value (Swami) Done
>>> >>> - Implement Data Model (Swami will push code to the gerrit) by
>>> >>> 5/20
>>> >>> - CLI (python-quantum client) work (Swami will push code to the
>>> >>> gerrit) by 5/20
>>> >>> - Implement Driver (Nachi & PCM ) by 5/31
>>> >>> - Investigate strongswan
>>> >>> - rpc (spec needed)
>>> >>> - Design driver archtecutre (spec needed)
>>> >>> - Write driver code
>>> >>> - Instation instructions on Wiki 5/31
>>> >>> - Devstack support (nati) late June?
>>> >>> - Write openstack network api document wiki (Sachin)
>>> >>> - Horizon work (needs contributer)
>>> >>> - Tempest (needs contributer)
>>> >>>
>>> >>> Next meeting is 5/16 Thursday at 3pm (PST) . On IRC
>>> >>> #openstack-meetings
>>> >>>
>>> >>> Meeting ended Tue May 14 01:00:58 2013 UTC. Information about
>>> >>> MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
>>> >>> Minutes:
>>> >>>
>>> >>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>> >>> 3/openstack_networking_vpn.2013-05-14-00.06.html
>>> >>> Minutes (text):
>>> >>>
>>> >>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>> >>> 3/openstack_networking_vpn.2013-05-14-00.06.txt
>>> >>> Log:
>>> >>>
>>> >>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>> >>> 3/openstack_networking_vpn.2013-05-14-00.06.log.htm
>>> >>>
>>> >>> Thanks!
>>> >>> Nachi Ueno
>>> >>>
>>> >>> 2013/5/10 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>:
>>> >>> > Hi Paul
>>> >>> >
>>> >>> > Thanks for your contributions! :)
>>> >>> >
>>> >>> > Nachi
>>> >>> >
>>> >>> > 2013/5/10 Paul Michali <pcm at cisco.com<mailto:pcm at cisco.com>>:
>>> >>> >> Sure! Glad to work with you Nachi. Anything I can do to help out
>>> >>> >> on the project!
>>> >>> >>
>>> >>> >> I'll start looking at strongswan and how to configure.
>>> >>> >>
>>> >>> >>
>>> >>> >> Regards,
>>> >>> >>
>>> >>> >> PCM (Paul Michali)
>>> >>> >>
>>> >>> >>
>>> >>> >> On May 10, 2013, at 12:35 PM, Nachi Ueno wrote:
>>> >>> >>
>>> >>> >> 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<mailto: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-3pQV
>>> >>> >> wp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.p
>>> >>> >>
>>> >>> >> Nachi
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> 2013/5/7 Qin Li <qili at vmware.com<mailto: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<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<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/1Jphcvnn7PKxqFEFFZ
>>> >>> >> Q1_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<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/1Jphcvnn7PKxqFEFFZ
>>> >>> >> Q1_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<mailto: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/1Jphcvnn7PKxqFEFFZ
>>> >>> >> Q1_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-3pQVwp5XgZDWPfzU
>>> >>> >> vuSqc
>>> >>> >>
>>> >>> >>
>>> >>> >> zRdK0lEZKQOKk/edit#slide=id.p
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> Thanks!
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> 2013/5/1 Sachin Thakkar
>>> >>> >> <sthakkar at vmware.com<mailto: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<mailto:sthakkar at vmware.com>>
>>> >>> >>
>>> >>> >>
>>> >>> >> To: "OpenStack Development Mailing List
>>> (openstack-dev at lists.openstack<mailto:openstack-dev at lists.openstack>.
>>> >>> >>
>>> >>> >>
>>> >>> >> org)"
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> <openstack-dev at lists.openstack.org<mailto: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=5c591a8916642e738e03c2558
>>> >>> >> 5184
>>> >>> >>
>>> >>> >>
>>> >>> >> f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298
>>> >>> >> f8a5
>>> >>> >>
>>> >>> >>
>>> >>> >> 9d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151
>>> >>> >> c4b3
>>> >>> >>
>>> >>> >>
>>> >>> >> 0a31fa1b2
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> To all interested, hope to see you there.
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> Cheers,
>>> >>> >>
>>> >>> >>
>>> >>> >> Sachin
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> _______________________________________________
>>> >>> >>
>>> >>> >>
>>> >>> >> OpenStack-dev mailing list
>>> >>> >>
>>> >>> >>
>>> >>> >>
>>> >>> >> OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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