Subject: [IPsec] DMVPN thoughts

From: Timo Teras <[email-masked]>
Date: Fri, 22 Nov 2013 22:05:29 +0200

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

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Tue, 26 Nov 2013 01:41:36 +0000

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
[email-masked]            .:|:.:|:.
Customer Advocacy          CISCO

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

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

>    conflicts with some RFC drafts), and it's CIE based payload content

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

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

> 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

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

> 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
> 
> [2]
> http://wiki.alpinelinux.org/wiki/Dynamic_Multipoint_VPN_%28DMVPN
> %29
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Timo Teras <[email-masked]>
Date: Tue, 26 Nov 2013 08:29:59 +0200

On Tue, 26 Nov 2013 01:41:36 +0000

> to hear that it wasn't "too hard" to do.  

:)

> I have a couple of comments, inline.

Likewise.

> >[snip]
> >  - 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.

Yes, I figured this. IMHO, the whole NHRP authentication is kinda
redundant since IPsec is used - but I just implemented it for
completeness. Not sure if it makes sense to use it in new installs. Or
does it add something on some scenarios? Or would it make sense to
specify that it is not recommended to be used.

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

Agreed. I believe this is more or less needed for proper interop in
scenarios where spoke is behind NAT. So this should be documented.

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

I observed this in 2008 - could have changed since then. But at least
back then I was unable to purge a binding unless the Request ID matched
to the one in the original Registration Request.

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

Oh - I somehow missed the RFC2332 on that. I need to fix that in my
code.

How you handle if the FQDN has multiple A-records? Do you just pick
one to be hub from it, or consider all as hubs? opennhrp will use them
all as separate hubs - so each client needs exactly one FQDN to pull
all hubs; and if records are added/removed it synchronizes to new set
of hubs properly.

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

How else would you handle per-dmvpn authentication then? If you have
two dmvpn instances that require different certs, it's not possible to
properly authenticate the GRE traffic unless per-key selector is used.

Otherwise I could give network A's cert and start sending stuff on
network B's GRE tunnel.

As somewhat related, but additional feature, opennhrp also allows hooks
on peer-up and peer-register events. And I also ship a rudimentary
example hook that pulls the IKE certificate, and checks it's
subjectAltName to have the GRE address requested in NHRP Registration
Request.

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

As additional note - after reading the other drafts. I think I like the
dmvpn approach most. The IKE extension thingy is certainly interesting
too.

Granted the intial implementation draft-sathyanarayan-ipsecme-advpn-00
looks simpler than dmvpn. But but I fear that more and more IKE
extensions need to be specified to handle things that DMVPN leaves to
be care of routing protocols.

E.g. in DMVPN it is simple to setup two gateway nodes for one site -
and do multipath, or primary-backup setups using BGP / OSPF. I believe
those setups would need additional IKE extensions to work properly in
the suggested draft-sathyanarayan-ipsecme-advpn-00 setup.

So IMHO, the big advantage in DMVPN is that network layers are done
properly, instead of trying to stuff all functionality to one place.

- Timo

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Tue, 26 Nov 2013 22:44:51 +0000

Timo,

 Comments Inline.

Mike.

Mike Sullenberger, DSE
[email-masked]            .:|:.:|:.
Customer Advocacy          CISCO

> From: Timo Teräs [mailto:[email-masked]] On Behalf Of Timo
> Teras
> Sent: Monday, November 25, 2013 10:30 PM
> To: Mike Sullenberger (mls)
> Cc: [email-masked]
> Subject: Re: [IPsec] DMVPN thoughts
> 
> > 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.
> 
[Mike Sullenberger] 

There is one use case where we run DMVPN without crypto, because
the customer has their own inline hardware encryptors.  They like to
use DMVPN in this case, because it presents a few tunnel flows to the
encryptor instead of thousands of user data flows. Making the
encryptors job easier.  So we will likely keep it, though it wouldn't hurt
to go ahead and implement a SHA(2) authentication to go with the
clear-text password.

[Mike Sullenberger] 

Yes, we will go ahead and document this in an update to the draft.

> I observed this in 2008 - could have changed since then. But at least back
> then I was unable to purge a binding unless the Request ID matched to
> the one in the original Registration Request.

[Mike Sullenberger] 
I know that over the last few years we have put some more work into
making NHRP purges work better. So perhaps we fixed this. 

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

[Mike Sullenberger] 
Yes it is a cute trick of setting the destination protocol address to be the
same as the source protocol address.  Then when the NHS responds it
replaces the destination protocol address with its own address and the
NHC picks it up from there.  Note, we did simplify the NHRP registration
processing, in that we only allow the NHRP registration to go one hop.
We didn't see any real usefulness in allowing NHRP registrations to be
routed.

> all as separate hubs - so each client needs exactly one FQDN to pull all
> hubs; and if records are added/removed it synchronizes to new set of
> hubs properly.
> 
[Mike Sullenberger] 
That is an interesting idea.  We just pick the first one from the list and
use that, another NHC may pick a different one from the list, due to 
DNS A record randomization, or any other criteria that the DNS chooses
to use to sort the list.

> > > 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]
> How else would you handle per-dmvpn authentication then? If you
> have two dmvpn instances that require different certs, it's not possible
> to properly authenticate the GRE traffic unless per-key selector is used.
> 

[Mike Sullenberger] 
I have to check exactly how it is done, but we can tie a GRE tunnel
interface to an ISAKMP/IKEv2 instance and then ISAKMP/IKEv2 instance
to a CERT chain.  So when an NHC authenticates via a specific CERT chain
then it is mapped/locked into a specific GRE tunnel interface instance.
The NHC would then NHRP register, and if that isn't successful then the
ISAKMP/IKEv2/IPsec SAs are cleared. So far this hasn't been something
we have worried too much about, but with opening this up to hosts we
May have to revisit this to make sure there isn't a security hole.

> As somewhat related, but additional feature, opennhrp also allows
> hooks on peer-up and peer-register events. And I also ship a
> rudimentary example hook that pulls the IKE certificate, and checks it's
> subjectAltName to have the GRE address requested in NHRP
> Registration Request.
>
[Mike Sullenberger] 
We added something like this, called Smart-spoke, for NHRP resolution
Requests, which allows the receiver of an NHRP resolution request to
execute a script, to take some action, one of which would be to accept
or reject the NHRP resolution request, but it can be used to do just about
anything. We need to look into expanding this to NHRP registration
request/reply and NHRP resolution reply.  We also have syslog and SNMP
notifications for all sorts of NHRP events.

> E.g. in DMVPN it is simple to setup two gateway nodes for one site - and
> do multipath, or primary-backup setups using BGP / OSPF. I believe

[Mike Sullenberger] 
This was one of the main tenets of DMVPN, I.e. making sure to use a layered
model (routing, mapping (NHRP), tunneling (GRE), and encrypt/auth(IPsec)
and keeping each layer separated.

Thanks,

Mike.