Re: [IPsec] DMVPN thoughts

["Mike Sullenberger (mls)" <[e-mail]>]

Timo,

Thank you very much for your comments. I had not realized that
anyone had tried to implement our additions to NHRP, it is nice
to hear that it wasn't "too hard" to do.  

I have a couple of comments, inline.

Mike.

Mike Sullenberger, DSE
[e-mail]            .:|:.:|:.
Customer Advocacy          CISCO

> -----Original Message-----
> From: IPsec [mailto:[e-mail]] On Behalf Of Timo Teras
> Sent: Friday, November 22, 2013 12:05 PM
> To: [e-mail]
> Subject: [IPsec] DMVPN thoughts
> 
> 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

[Mike Sullenberger] 
Yes you are correct,  back in 1995 when the initial NHRP implementation
was done, only a simple clear-text authentication was done using a SPI
value of 1 and not including the src-addr field, just the Authentication Data
field.  Since then we have thought about fixing this, but since DMVPN is
encrypted with IPsec and we use the strong authentication in ISAKMP/IKEv2,
there hasn't been a big impetus to get this fixed.

>  - NAT address extension (code 9; Cisco specified, and apparently even
>    conflicts with some RFC drafts), and it's CIE based payload content
>    specification

[Mike Sullenberger] 
This is true.  In hind-sight we probably should have made this a vendor
private extension.

>  - 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).

[Mike Sullenberger] 
I would have to check this, but I don't think that we bother to match up
the request-id from a purge message with the original resolution
request/reply that created the mapping entry. We do match the request-id
between the resolution request and reply.

> 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.

[Mike Sullenberger] 
We do have this mechanism now.  You can specify the NHS as a FQDN and
at tunnel initialization time we will use DNS to translate the name to an
address.  From then on the address is used, though if access to the NHS goes
down then we initial retry with the address, but if that still fails we will do
another DNS lookup on the name in case the address has changed.  We also
use the mechanism as described in RFC2332 to get the NHS network address
from the NHRP registration reply.

> 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.

[Mike Sullenberger] 
I am not really that "keen" on adding GRE tunnel key negotiation to IKE. I
prefer keeping these two layers a little more separated.  Though I possibly
could be convinced otherwise.

> 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
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec