Kernel IPSec Questions
T C
I have some questions on how IPSec logic works in the kernel. There might be
a difference between when XFRM was introduced and prior. If possible,
I like to know both scenarios. If not, at least from XFRM perspective would
be very helpful.
Specifically, I am interested in knowing how does IPSec obtain the initial keys
from IKE exchange (and likely from XFRM) to set up the SA. Also what happens
during rekeying? Does the SA have to be terminated first, or somehow it can be
rekey'ed and continue as the same SA? I'll be using strongswan for IKE.
Function names and if possible some flow graphs would be greatly appreciated.
Thanks,
Terry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andreas Steffen
here a repost of my email including the netdev list and fixing
the last URL which was wrong.
Here the definition of strongSwan's IPsec high level kernel interface
and here the link to the kernel-netlink plugin which implements
configuration and management of IPsec Policies and SAs via XFRM
Our plugin of course relies on the ipsec.h, netlink.h, rtnetlink.h,
and xfrm.h Linux header files which define the API of the XFRM Netlink
kernel interface
Much more documentation than the Linux header files and the XFRM kernel
source code itself does not exist.
Finally a link which shows how strongSwan installs, updates, queries
and deletes IPsec Policies and SAs
Just look for all "hydra->kernel_interface" function calls.
Best regards
Andreas
--
======================================================================
Andreas Steffen andreas...@strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
T C
Thanks for the URLs. I'll look thru them.
As far as strongswan is concerned, Martin has been very helpful in
explaining all the active actions that StrongSwan takes from
the user side. So actions taken by IKE daemon based on configuration
files I already have info on that. However,
the part that remains mostly unfamiliar is those actions taken by the
kernel during rekeying by sending messages back
from the kernel to the IKE daemon. Do you happen to know anything
about that? How are those actions trigged and what
happens to the communication channels during rekeying is what I am
most interested in finding out. If your URLs already
contain something that'll point to those, I'll find out from them. If
there is additional info on this, could you share them
as well?
Thanks,
Terry
Andreas Steffen
each IPsec SA in the kernel has a lifetime configuration consisting
of both a soft and a hard limit for the number of bytes, number of
packets and time:
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 903(sec), hard 1200(sec)
expire use: soft 0(sec), hard 0(sec)
Each time one of the soft or hard limits is reached, the Linux kernel
generates an XFRM_MSG_EXPIRE message to which the charon daemon
subscribes when creating the NETLINK_XFRM socket:
The callback function receive_events() is triggered by these
subscribed XFRM messages:
In the case of XFRM_MSG_EXPIRE the function process_expire() is
called:
which in turn calls hydra->kernel_interface->expire():
All registered expire listeners are notified, in our case the libcharon
listener:
As you can see, if a soft limit was reached then a CHILD_SA rekeying
job is scheduled
job = (job_t*)rekey_child_sa_job_create(reqid, proto, spi);
and if a hard limit is reached (what should not happen with rekey=yes)
then the CHILD_SA is deleted
job = (job_t*)delete_child_sa_job_create(reqid, proto, spi);
Best regards
Andreas
======================================================================