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
