Open Stack

Hi Francois, Paul

Thank you for your investigation

using chroot is may be one option however it sound little bit tricky.
so let's use check openswan has enough functionality for first implementation.
( may be, we can also have strongswan driver in future)


2013/5/22 Eleouet Francois <f.eleouet at gmail.com>:
> Hi,
>
> In the examples, the IPsec tunnel is set up between the namespaces moon and
> sun, they are linked by the veth pair. It may be more representative (and
> easier to set-up) than multiple VMs, as in turn we'll have to be able to
> support several IPsec instances in the same l3-agent (one for each
> netns/q-router handling VPN service)
>
> Regarding openswan features, well, good question... On the one hand, it
> seems to be actively supported, integrated in most distros, and have all the
> required features regarding VPNaaS requirements (it may lack some extra
> features like smartcard/HSM support but that shouldn't be a big deal). On
> the other hand, it provides less documentation and may be less popular, thus
> less tested and debugged... (personnally, I never played with it before)
>
> One option to use strongswan "as is" may be to use containers, as chroot or
> lxc with mount-bind, aufs or unionfs. It would provide extra security but
> the driver woud be more complex...
>
> We could also try to upstream changes to Strongswan (actually it looks like
> only small changes are needed in charon.c). I'll at least ask on their
> mailing list, I may have missed something, they may have some options to
> fire-up several charon daemons on the same host (for developpement/testing
> purposes?)
>
> Last option would be to have netns aware usespace daemons, as discussed
> here, but it's another story...
>
> Francois.
>
>
>
> 2013/5/22 Paul Michali <pcm at cisco.com>
>>
>> Do we know if openswan supports all the features we require (I'm just
>> starting to look at docs)?  Do we know if there are any bugs/issues that
>> will concern OS use?
>>
>> Regards,
>>
>> PCM (Paul Michali)
>>
>> On May 21, 2013, at 4:40 PM, Nachi Ueno wrote:
>>
>> 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
>>
>>
>> ...
>>
>> [Message tronqué]
>> _______________________________________________
>> 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
>