Subject: [IPsec] AD VPN: discussion kick off

From: Yaron Sheffer <[email-masked]>
Date: Wed, 23 Oct 2013 23:58:34 +0300

Hi everyone,

We spent a lot of time understanding the requirements from autodiscovery
VPN solutions, and we have 3 serious proposals on the table. We have had
in-depth presentations of two of them
(http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03.txt and
http://tools.ietf.org/html/draft-detienne-dmvpn-00 respectively) in
Berlin and the last interim meeting. We will have the third in-depth
presentation (of
http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02.txt) in
Vancouver.

It is now time to start the selection process, so that we end up
adopting one proposal into the working group, and developing it together
into an RFC with WG consensus. We will not make the final selection in
Vancouver, but we would like to use the time before, during and after
the meeting to advance this process. With that in mind, we would like to
request each author team to present 3-5 bullet points explaining why
their solution is preferable compared to the alternatives. Please send
your comparison to the list so we can start a serious discussion before
the meeting and make the best use of our face time.

Needless to say, please keep the discussion civil and to the point, even
when comparing your perfect solution with the other obviously inferior
kludges :-)

Thanks,
         Paul and Yaron

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Oct 2013 14:08:47 +0000

Hi

I think one of the most striking things is how similar all three mechanisms are.

They all begin with a node doing what the DMVPN guys call a "hairpin" - it decrypts packets from one peer, then re-encrypts them and sends them to another peer.

In all three proposals, the node doing the hairpin notices this inefficiency, and informs one or both of the peers.

In all three proposals, the peers learn of each other, and open a direct tunnel. 

The semantics are practically identical, so the difference is only in the mechanism. 

In our proposal (draft-sathyanarayan), it is the hairpin node that does the introduction, which takes place at the same time as the notification.
In draft-mao there is an omniscient server known as ADS that the peers ask for tunnel information
In DMVPN the peer runs a discovery process using NHRP over a GRE tunnel.

Our proposal in an IKE extension
draft-mao defines a new UDP-based protocol
DMVPN (draft-detienne) uses NHRP over a GRE tunnel

As a document, I think ours has the advantage of being more complete. Both DMVPN and the other ADVPN gloss over authentication, identities and authorization. Mike pretty much said it in the conf call: any gateway that has a valid certificate will connect, and will be trusted. There might be some routing protocol security, but that is outside scope, and anything based on RPKI is unlikely in corporate networks. Those are, however, gaps that can be filled. Whichever proposal gets chosen is only a starting point, and the WG can decide to tightly profile the authentication and authorization in any proposal, as well as augment any of the protocols with identities and credentials.

Our advantages are:
- fewer packets, because notification, introduction and credential provisioning are all done in one round-trip.
- Less complexity, as it's all in an IKE extension (compared with the new protocol of ADVPN2 and the whole GRE+NHRP+routing protocol implementation of DMVPN)
- Works with IPsec tunnels (no need for an extra GRE tunnel)
- Requires no new components which can be points of failure (like an ADS)
- Scalability. Consider 10,000 remote access clients
   - Mike said you could do that with GRE. The fact is that Cisco's clients use IPsec tunnels or L2TP, neither requires a virtual interface on the gateway. Running GRE and routing protocols to the clients is not done, and probably for a good reason. I've also been told that having a large number of neighbors is a problem for routing protocols (although I'm no expert on those)
   - ADS is an obvious potential bottleneck. Loss of state there can be devastating - how would it recover the data?  OTOH we have the ability to keep servers running without losing state. It costs money, but servers can work reliably and scalably. Just look at the Facebook web servers :-)

Our disadvantages:
- Shortcuts work a single hop at a time. If the path through the VPN is longer, we may set up some useless SAs.
- Not tested in the field

Yoav