On Tue, 5 Apr 2016 23:19:54 +0300 Timo Teras <[email protected]> wrote:
> On Tue, 5 Apr 2016 15:50:28 -0400 (EDT) > Paul Wouters <[email protected]> wrote: > > > On Tue, 5 Apr 2016, Timo Teras wrote: > > > > > 4. Get information of CHILD SAs. The idea is that nhrp can then > > > flush all nhrp mappings when last CHILD SA expires (or is killed > > > by DPD). > > > > so we have ipsec whack --trafficstatus but I guess you want a > > listing of "conn-name source/mask <-> dest/mask" ? If there are > > many like you suggest, would you want to ask pluto based on a conn > > name or a prefix? > > I would probably want through connection name. In dmvpn the > traffic selector is basically "Transport mode, GRE". IPsec+GRE is used > purely as transit tunnel mechanism. BGP, OSPF or other routing > protocol is run inside to figure out what traffic should go where. > NHRP complements this by 1) keeping the GRE IP<->public IP bindings > and 2) assisting the routing protocol to create shortcut routes to > bypass hub nodes when possible (however, it's the routing protocol > that maintains the routes and decision where traffic is flowing. e.g. > on BGP withdrawal all nhrp shortcuts are immediately flushed). > > Basically I'd like to maintain one socket between nhrp and pluto. I > can then send command such as: > "Enumerate, and send updates for all IKE_SA and CHILD_SA with > connection name 'foo'" > > And then I'd hope to get first a full dump, and later a push style > notification of any notable additions/deletions/changes. I do not need > to track traffic counts, idle times or so. I basically need to track > if "valid CHILD_SA exists" and "what is the IKE_SA authentication > data". > > > > So I'm wondering if there would be interest to get a more stable > > > api to control libreswan supporting (at least) the above three > > > features. Ideally, it'd be single unix socket connection that is > > > event based (asynchronous) and accepts initiate/terminate requests > > > and provides the ike/child sa notifications (+ sa db > > > synchronization on connect in case nhrpd is restarted). > > > > Whack in the end is also a simple socket, and you could implement > > whack in your app so you can just use a socket. But perhaps we need > > to give you a separate socket so there is no risk of accidentally > > blocking. > > Yes. That would be ideal. I would hope that: > > a) whack is stable and would have at least some backwards > compatibility so that app does not need to updated too often when a > some minor new feature is added to whack. Currently it seems to be > very sensitive to the rpc structure. > > b) it would require only one socket connection. now whack connects for > each initiate request, and pluto terminates the status socket when > done. so events could be sent over the same socket (thus avoiding > reconnecting / requiring simultaneous connects). > > This would also help because of the way shortcuts are established. > Normally when two spoke nodes start to talk to each other, the traffic > is first relayed through the serving hub node. However, the hub will > then send nhrp traffic indication to both asking them to establish > direct tunnel. They can end up initiating IKE_SA simultaneously to > each other, so passing all events through one socket helps up to > avoid race conditions. > > > Thanks for reaching out to us, and let's keep the conversation going > > to make this work with libreswan. > > Thanks for the positive response! Will do! Regarding the above functionality. Would it be something that the core developers of libreswan could help to implement? Or something I need to write? Seems the things to implement in code would be: - Implement / improve whack to support: * persistent socket connections * if possible some serialization format that is stable across versions (instead of the static struct currently) - Hook the parent/child SA notifications. Basically to places where linux_audit_conn() is called, just add also the new notification dispatching call too. Any additional thoughts on how to pursue these features further? Thanks, Timo _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
