[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    Re: [Ipsec-tools-devel] Programmatic control of adding/removing SAs and policies
From:       Mohammad Ahmad <mohd.ahmad17 () gmail ! com>
Date:       2015-07-09 20:27:35
Message-ID: CADdJpvpDi5_48Y9ZLXe36Wo7s3zPYwqVY2iJeV9hOteMDk-A8A () mail ! gmail ! com
[Download RAW message or body]

Thank you guys for the detailed response. Can you comment on the
difference between using IP Xfrm in this scenario? How does setkey
differ? Thanks!

Ahmad

On Thu, Jul 9, 2015 at 8:30 AM, Rainer Weikusat
<rweikusat@mobileactivedefense.com> wrote:
> Mohammad Ahmad <mohd.ahmad17@gmail.com> writes:
>> rweikusat@mobileactivedefense.com> wrote:
>>> Mohammad Ahmad <mohd.ahmad17@gmail.com> writes:
>>> > I want to be able to add, remove security associations and policies
>>> > based on some network events. Currently, I exec() the setkey commands,
>>> > I expect there is a better way. Is libipsec the way to go with this?
>>> > Any others suggestions? I appreciate the help, thanks!
>>>
>>> IMHO, you should stick with executing setkey unless you have a tangible
>>> reason to do otherwise (which would be something like "you're creating
>>> thousands of policies"): There's nothing wrong with using exisiting
>>> programs to perform the tasks they're supposed to perform.
>
> [...]
>
>> Right. I have a use case for hundreds of policies. I was thinking
>> libipsec may make the software easier to ship.
>
> *If* you're planning to use the existing ipsec-tools code, you could use
> libipsec to parse setkey-style policy etc specifications and libpfkey
> to communicate with the actual IPsec layer (in the kernel). But the
> question is "what do you expect to gain from that"? Executing a setkey
> command per change means there'll be a fork and an exec per change. The
> last time this overhead actually caused performance problems in a
> situation I had to deal with was when creating hundreds of 'Linux
> firewall rules' by individually invoking the iptables program on an
> embedded system using a 133Mhz ARM9 processor years ago. Unless you're
> in a very specific situation, it's extremely unlikely that this will
> matter for you. Even if it does, there are alternate options to
> 'reimplementing setkey' to some degree. Eg, you could start it once and
> send a script making all of your policy changes to it and with some more
> effort, you could also turn it into coprocess which executes 'setkey
> code' line-by-line and supports a simple, bidirectional protocol so
> that the controlling program can operate in lockstep with the coprocess
> if so desired.
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ipsec-tools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
[prev in list] [next in list] [prev in thread] [next in thread]