HI, I went through the stronswan code to understand the IKE_SA and CHILD_SA creation .
While going through the code I came across acquire function. The comments for the function indicate that it processes the trigger from the kernel for creation of CHILD_SAs. 1. Is it the only mechanism through which the CHILD_SAs can be created ( i.e through the acquire function, trigger coming from the kernel based on policies installed ) 2. The function also mentioned that the IKE_SA creation can also be triggered through the acquire function sometimes. What are the scenarios under which the IKE_SA creation can be triggered from the kernel? I would highly appretiate your help on these issues. Looking forward for a reply. Thanks, Vivek On 7/6/09, vivek bairathi <bairathi.vi...@gmail.com> wrote: > Hi, > > Thanks for your help. > > I still have a doubt that who initiates the IKE SA and CHILD SA. > 1. Is it kernel who initiates both? > 2. Or Kernel just initiates the CHILD SA (through acquire() function > as per the SPD) and the IKE SA is initiated/triggered by reading the > ipsec.conf file from which he knows the local and remote IP addresses? > 3. If I have asked the wrong question or have wrongly understood your > stack code then please do explain me how an IKE SA and CHILD SA is > initiated or triggered in your stack? > > > Thank you. > > Regards, > Vivek > > > On 7/2/09, vivek bairathi <bairathi.vi...@gmail.com> wrote: >> Hi Martin, >> >> Thanks for your help. The problem is that we have a propritary >> implementaion of the IP stack in micro engine whose development is in >> assembly language. >> >> As per what you have suggested, I think it would make sense that we >> let the kernel interface remain as is ( just change address family of >> the sockets with compatiple ones ) and let another process sniff these >> messages and provide an adpater interface with the network >> processor/micro engine. This adapter would then provide all required >> interfaces to the strongswan >> >> What are your thoughts on the same ? >> >> Regards, >> >> Vivek. >> >> >> >> >> On 7/2/09, Martin Willi <mar...@strongswan.org> wrote: >>> Hi, >>> >>>> 1. Could you please throw some light on how is the updated IP list is >>>> given to the stack >>> >>> The roam job just indicates the network configuration has changed. While >>> processing the job, a route lookup is done to find a new (or keep the >>> existing) path to reach the peer. >>> >>>> 2. We saw that the XFRM_Expire message is received from the kernel. >>>> Is it then the correct assumptions that strongswan does not maintain >>>> the re-keying timer for the child SAs? >>> >>> Yes, IKE_SA lifetimes are handled in the daemon, while CHILD_SA >>> lifetimes are handled in the kernel. The reason for this is that there >>> are (theoretically) other ways to expire an SA, only known to the kernel >>> (e.g. number of bytes/packets processed). >>> >>>> 3. Could you let us know the best approach for plugging out the kernel >>>> interface and using our own? >>> >>> Removing the kernel interface is probably the most complex option, you >>> would need to work around a lot of functionality in the core daemon. >>> >>> The right way to do it is implement a kernel interface for IPsec and >>> networking for the QNX system. >>> >>> QNX uses a PF_KEY interface [1], so you could try to use our existing >>> PF_KEY plugin. As NetBSD uses a policy handling concept similar to KLIPS >>> (flows), you probably need to borrow some bits from the KLIPS plugin. >>> >>> For the networking part, QNX uses the PF_ROUTE protocol [2] from BSD. >>> You could try to use our PF_ROUTE plugin. It should work, but might not >>> be feature complete. >>> >>> >>> If you are willing to sponsor the development, you could hand over your >>> QNX porting efforts to us. The strongSwan team has some experience in >>> porting to BSD based systems... >>> >>> Regards >>> Martin >>> >>> [1]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ipsec_proto.html >>> [2]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/r/route_proto.html >>> >>> >> > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
