[openstack-dev] VPNaaS
Eleouet Francois
f.eleouet at gmail.com
Mon May 20 11:22:36 UTC 2013
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/3ffae3c0/attachment.html>
More information about the OpenStack-dev
mailing list