[IPsec] DMVPN thoughts

[Timo Teras <[e-mail]>]

Hi everyone,

Yaron Sheffer recently invited my to share my thoughts on DMVPN as it
seems to be one of the option being considered to be the AD VPN
standard.

As brief background, I am the author of opennhrp [1] which can be used
to implement Cisco DMVPN style networks on Linux [2]. I have also
written multiple improvements to Linux kernel to support this kind of
networks. Additionally, I have enhanced ipsec-tools (racoon) [3] to be
suitable for this use, and am currently looking into integrating
opennhrp with strongswan [4].

The opennhrp project started back in 2007. It was implemented based on
the NHRP specification (RFC 2332) and with some insight take from
draft-ietf-ion-r2r-nhrp-03. The remaining Cisco NHRP extensions I
implemented based on protocol analysis. While it is not perfect match
with Cisco DMVPN, I have good success interoperating with Cisco
devices. The feature set of opennhrp is not as complete as Cisco - e.g.
IPv6 is not (yet) supported.

It would have been very helpful to have draft-detienne-dmvpn-00 at the
time I was writing most of the code. I did considerable testing against
Cisco devices in 2007-2008 but since have been concentrating more on
fully opennhrp based DMVPN networks - so I have not paid close
attention on the latest Cisco updates.

However, after brief read of the draft, it seems to be missing at least:
 - Authentication extension (code 7; from RFC 2332) payload format which
   seems to be Cisco specific - at least RFC 2332 does not specify it
 - NAT address extension (code 9; Cisco specified, and apparently even
   conflicts with some RFC drafts), and it's CIE based payload content
   specification
 - The specifics how Request ID field should be used. My experience
   shows that Request ID is stored along with the registrations, and
   needs to match in Purge requests for the Purge operation to succeed
   (IMHO, such Request ID matching should not be done).

The one defect for me with DMVPN was that hubs are not automatically
discovered (or maybe there's something for this nowadays?). Thus
opennhrp has one extension: "dynamic-map" configuration stanza. It
binds the NHSes to a DNS entry. The A records of that DNS name are
used as NBMA addresses of the NHSes. During initial NHRP registration
the NHRP Registration Requests are sent to the network broadcast
address with hop count 1, and the NHS network address is picked up from
the NHRP Registration Reply. The list of NHS servers is of course
synchronized regularly. So as minimum, this or some similar hub
autodetection mechanism should be added to dmvpn spec.

Additionally, running multiple DMVPN instances on single router would
require a standards compliant way to negotiate GRE key in IKE
traffic selectors. There seems to have been discussions about that back
in 2008 on this list, but it seems nothing came out of it. So I think
this issue should be brought to discussion again too.

I personally do like how the DMVPN stack works and would like to see
it standardized. However, I do understand that it might not be perfect
fit or even preference for all.

Cheers,
 Timo

[1] http://sourceforge.net/projects/opennhrp/
[2] http://wiki.alpinelinux.org/wiki/Dynamic_Multipoint_VPN_%28DMVPN%29
[3] http://ipsec-tools.sourceforge.net/
[4] https://lists.strongswan.org/pipermail/dev/2013-November/000945.html