[Openswan dev] New IPsec user application

Oliver Carter olivercarter_google at yahoo.co.uk
Wed Apr 25 13:26:47 EDT 2007

  I'm relatively new to Linux, IPsec and this mailing list, so let me know if I've posted to the wrong list or if this mail is out-of-scope.
  I'm looking to develop an application that will set up IPsec security associations (SAs) and policy on demand. This application doesn't use IKE, it's a proprietary system I'm working on.
  In this system, there is no requirement to set up SAs as a result of policy demand. SAs and the policy that refers to them will be programmed at the same time, so when the policy-engine tries to find a suitable SA for a packet, one should always be available (or if not, the packet should be dropped).
  I'd like to base my implementation on OpenSwan and Linux Kernel (ideally 2.6 and above), but I have a few questions below as to whether it would be suitable.
  Multiple SAs need to be supported to a given endpoint (IP address).  The choice of SA (for outbound packets) is controlled by the transport level ports, so IPsec policy needs to be able to associate a specific SA with a particular flow (flow being src+dest IP address, transport protocol and ports).  
  1.  Is there any way to support this with OpenSwan's standard policy and SA programming APIs?
  In an attempt to answer my own question, I've taken a look through the source code of the 2.4.7 release.  It appears that this is supported through the SADB_X_EXT_ADDRESS_SRC_FLOW and SADB_X_EXT_ADDRESS_DST_FLOW PF_KEYv2 extensions.  These appear to extract the source/dest ports from the PF_KEY sadb_message and build them into the eroute tree.  Then I believe the lookup in ipsec_tunnel_SAlookup() should preferentially match eroute entries that having matching ports, addresses and protocol.  
  2.  Can anyone confirm or deny my understanding here?
  3.  Is there any documentation of this feature, that I should have read before posting :-)?
  4.  I had previously thought of the PF_KEY interface as SA programming only.  Associating an SA with a flow in this way seems to verge into policy.  Are there any corresponding policy changes I will need to make to get this to work?  
  Any answers appreciated, even if it's an answer along the lines of "this isn't supported - you're on your own". 

 Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/dev/attachments/20070425/c4e6d7b4/attachment.html 

More information about the Dev mailing list