[strongSwan-dev] Dynamic Multipoint VPN (opennhrp) with strongswan

[Timo Teras]

Hi,

On Mon, 18 Aug 2014 10:44:13 +0200
Martin Willi <martin at strongswan.org> wrote:

> > This seems to be where 'vici' does already a majority of the work.
> 
> > 1) Send notifications on SA creation/deletion. Should simple to add
> > as list-sa already does the tedious work of serializing the
> > information.
> 
> Re-using that code certainly would make sense. Registering a listener
> to the bus is rather simple. Then you'd need to add a vici event, and
> allow clients to register for it.

Right.

> > Would be practical if x509 cert was sent automatically in the
> > notification too.
> 
> Doable, probably we should make that optional, as this will be a lot
> of data, especially if you include CA certificates as well.

Fair enough. Either different named event, or some attribute to pass
during event registration?

> > 2) A way to request instantiation/termination of transport mode
> > "right=%any" connection with specific value for 'right'. Needed to
> > bootstrap spoke-hub connections (and hub-hub depending on config).
> 
> If you have the associated up/down events for IKE_SAs, you may cache
> unique connection identifiers in the client and use the existing
> termination command.
> 
> Adding an additional remote IP selector to the existing terminate
> command is not complicated, either.

This needs some though.

Initiation would need new attribute for remote IP in any case.

For termination, generally all SAs to specific 'node' need to be
deleted. Normally that would be all SAs to specific remote IP + ID
pair. As you might have two nodes NATted behind same public IP.

> > 3) Additional 'connection configuration origin' field. So that dmvpn
> > and swanctl can manage their set of configs without deleting each
> > others conn entries on reload.
> 
> I had this in mind during the initial protocol design, but didn't
> implement it yet. Certainly something we need in the future.
> 
> My idea is to introduce namespaces, where all the configuration
> related things are attached. You then can create or select a specific
> namespace to work in.
> 
> Such an extension is not that trivial, and probably requires changes
> to the vici core message handling. I'll see if I find time to
> implement something like that.

Ok. That would work even better.

> > 4) Way to influence CFG_REQUEST/CFG_REPLY/CFG_SET during
> > negotiation. This would be required for full Cisco compatibility as
> > they use those to exchange the IP-configuration. Though, as first
> > step, I plan to be defining those in the x509 certificate.
> 
> If that is a pure Mode Config exchange in pull or push mode, I think
> that is mostly there in the vici_attributes virtual IP and attributes
> backend. Create a pool referenced by your connection, and add
> attributes to it. You might need additional keywords for custom
> attributes, but that should be trivial to implement.
> 
> We currently negotiate attributes only on connections assigning a
> virtual IP; not sure how this affects the DMVPN scenario.

I believe Cisco is a bit flexible on this.

You can configure the IP statically on nodes, or dynamically via
CFG_REQ(IP4_ADDRESS). Also this IP should be managed by nhrp side
(especially on hub routers), as it needs to be advertised via routing
protocols (kernel FIB, BGP).

Additionally, on "simple" nodes with statically routed subnets,
CFG_REQ(IP4_SUBNET) is sent. Hub replies with a static "aggregated
prefix list" reply.

Finally, the spoke announces it's subnets to hub with
CFG_SET(IP4_SUBNET). Hub filters them through acl before announcing to
routing protocols.

So there's two independent exchanges:

1) virtual IP request via IP[46]_ADDRESS, which I would like to handle
(assigning from pool is ok, but I need to run code for each assigned IP)

2) exchange of routes via IP[46]_SUBNET - both as CFG_REQ and
additional CFG_SET exchange

The route exchange happens only for "simplex" hub-spoke connections.
Hub-hub and complex hub-spoke run routing protocols, e.g. iBGP. And
spoke-spoke tunnels are discovered on demand via NHRP (traffic
indication + resolution request/response).

-Timo