On Tue, 26 Nov 2013 01:41:36 +0000 "Mike Sullenberger (mls)" <[email protected]> wrote:
> 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. Likewise. > > From: IPsec [mailto:[email protected]] On Behalf Of Timo Teras > > Sent: Friday, November 22, 2013 12:05 PM > > To: [email protected] > > Subject: [IPsec] DMVPN thoughts > > > >[snip] > > 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. 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. > > - 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. 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. > > 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. 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
