[Openswan dev] New IPsec user application
olivercarter_google at yahoo.co.uk
Thu Apr 26 04:51:41 EDT 2007
Great - thanks for the pointers. I'll try those lists now. I take it http://marc.info/?l=linux-netdev is the best place to ask for questions about XFRM and KLIPS and the NETKEY interface?
On the question of IP fragmentation - in my scenario all packets to be sent over these SAs are (or should be) originated by my application and sent over the standard sockets interface. So any IP fragments should only be created by the outbound IP stack. I believe (and my reading seems to confirm this), that IPsec encapsulation of an outgoing packet occurs before any IP fragmentation of those packets. So hopefully my ports will still be available.
Of course in the general case of traffic forwarding (say if the device is acting as a router), you're correct that this approach will not work.
Please let me know if I've misunderstood, or if you know of an easier way to achieve what I want (say a socket option that allows you to specify the SA to use for traffic sent over this socket).
Ulrich Weber <uweber at astaro.com> wrote:
it's not quite the right mailing list. You could try http://
What you wanna do has nothing to do with openswan.
IPSec in Linux consists of kernel space and user space code.
Kernel space is either XFRM (Linux Native IPSec for 2.6)
or KLIPS (Kernel IPSec implementation by Freeswan/Openswan for
User space (IKE program) is either openswan's pluto or racoon.
Their purpose is to install/delete SA (Security Associations) in
via PF_KEY or NETKEY interface.
For more information about PF_KEY you can play with setkey program,
For more information about NETKEY you can play with a
recent iproute2 version, e.g. "ip xfrm state add ..."
> 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).
Not possible with the IPSec standard (Only IP/Protocol ID is supported).
You dont have port information for each packet (IP fragmentation!).
However you could abuse connection tracking for that and extend
kernel IPSec ...
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev