[Swan-dev] quagga/nhrp integration to libreswan

[Timo Teras]

On Tue, 5 Apr 2016 23:19:54 +0300
Timo Teras <timo.teras at iki.fi> wrote:

> On Tue, 5 Apr 2016 15:50:28 -0400 (EDT)
> Paul Wouters <paul at nohats.ca> 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