[openstack-dev] VPNaaS
Paul Michali
pcm at cisco.com
Mon May 20 19:34:40 UTC 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/e47444f4/attachment.html>
More information about the OpenStack-dev
mailing list